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1.  INTRODUCTION 


1.1  Overview  and  Purpose 

This  document  analyzes  the  viable  alternatives  available  to  the 
Bureau  of  Land  Management  for  modernizing  its  ADP  technical  architecture 
( i .  e . ,  the  overall  configuration  of  computer  hardware,  systems  software,  and 
communications  networks  that  support  the  Bureau's  operations).  This  analysis 
is  part  of  the  fifth  major  deliverable  produced  under  American  Management 
Systems'  contract  to  support  BLM's  ADP  Modernization  Project,  a  multi-year 
effort  to  improve  the  Bureau's  ADP  capabilities. 

During  previous  tasks,  AMS  presented  BLM  with  alternatives  for  meeting 
BLM's  needs  for  ADP  and  telecommunications  support  and  a  brief  description  of 
the  evaluation  criteria  to  be  used  in  evaluating  these  alternatives.  The 
chief  purpose  of  this  report  is  to  further  refine  the  alternative  acquisition 
methods  and  alternative  system  architectures  that  are  feasible  for  BLM  given 
the  constraints  imposed  by  current  system  development  initiatives,  functional 
requirements  for  ADP  support,  and  other  factors.  These  were  identified  by  AMS 
in  the  Workload  Analysis  for  the  Bureau  of  Land  Management  ADP  Modernization 
Project,  delivered  to  BLM  March,  1986;  the  Functional  Requirements  Analysis 
for  the  8ureau  of  Land  Management  ADP  Modernization  Project,  delivered  to  BLM 
April,  1986;  and  the  Discussion  of  Objectives,  Constraints,  and  Implementation 
Considerations,  delivered  to  BLM  October,  1986. 

The  results  of  this  analysis  will  serve  as  input  to  Task  8,  an  Economic 
Analysis  of  the  feasible  alternatives. 

This  document  assumes  that  the  reader  is  familiar  with  the  organization 
and  mission  of  BLM.  Readers  unfamiliar  with  the  Bureau  may  refer  to  the  Task 
1  deliverable  of  the  ADP  Modernization  Study  or  documentation  such  as  the  BLM 
Annual  Report  (available  from  the  BLM  Office  of  Public  Affairs)  for  further 
details. 
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1.2  Project  History 


The  Bureau's  ADP  requirements  are  currently  supported  by  a  network  of 
computers  located  primarily  in  the  Denver  Service  Center  (DSC)  and  State 
Offices.  These  systems  are  rapidly  reaching  capacity  saturation  as  well  as 

obsolescence.  In  addition,  the  Bureau  uses  computers  owned  by  other 

organizations  —  such  as  the  U.S.  Geological  Survey,  the  Bureau  of 
Reclamation,  the  Forest  Service,  and  the  Bonneville  Power  Administration  —  to 
support  specific  applications  on  a  timesharing  basis.  Not  all  of  BLM's 
programmatic  and  management  information  requirements  are  being  met  by  the 
current  technical  architecture  (i.e.,  the  hardware,  systems  software,  network 
capabilities,  and  related  facilities  required  to  support  BLM's  ADP 
requirements).  Several  functional  areas  have  been  identified  which  would 
benefit  from  automation;  and  BLM  has  initiated  certain  projects,  such  as  the 
Automated  Land  and  Minerals  Records  System  (ALMRS).  The  current  ADP  systems 
cannot  accommodate  these  planned  BLM  applications. 

For  a  detailed  description  of  BLM's  existing  ADP  capabilities,  the  reader 
i s  referred  to  Existing  Capabilities  for  the  Bureau  of  Land  Management  ADP 
Modernization  Project,  delivered  to  BLM  by  AMS  June,  1986. 

In  order  to  upgrade  its  ADP  capabilities,  BLM's  Division  of  Information 
Resources  Management  (W0-77Q)  has  procured  the  services  of  American  Management 
Systems  (AMS)  to  perform  an  ADP  and  Data  Communications  Modernization  study 
(ADEMP).  The  project  is  intended  to  accomplish  the  following  objectives: 

o  Define  BLM's  current  and  future  functional  requirements  for 
ADP  and  data  communications  support. 

o  Document  the  capabilities  of  BLM's  current  hardware  and 
software,  and  analyze  any  deficiencies  in  meeting  current  and 
future  requirements. 

o  Identify  the  most  efficient  and  cost-effective  ADP  hardware, 
software,  and  data  communications  conf iguration  based  on  a 
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economic  analysis  of  alternative  concepts. 

o  Prepare  a  configuration  management  plan  with  which  to  control 
the  acquisition  and  management  of  any  needed  hardware, 
software,  and  communications  capabilities. 

o  Specify  the  technical  requirements  for  any  new  ADP  technology 
that  BLM  may  elect  to  procure. 

The  ADEMP  study  provides  a  technical  architecture  framework  for  all  of 
BLM's  data  systems.  It  is  the  purpose  of  this  study  to  ensure  that  all  BLM 
current  and  future  functional  requirements  are  supported  by  an  integrated  ADP 
and  data  communications  environment  to  the  extent  that  is  feasible.  Figure 
1-1  depicts  the  tasks  to  be  performed  under  AMS'  contract.  AMS'  work  will  be 
completed  by  the  end  of  fiscal  1987,  with  new  ADP  equipment  being  installed 
beginning  in  approximately  1990. 

1.3  Major  BLM  Initiatives  Related  to  ADEMP 

The  ADEMP  Study  addresses  the  hardware,  system  software,  support,  and 
data  communications  needs  of  all  of  BLM's  current  and  future  applications  for 
the  next  ten  years.  A  number  of  other  studies  were  initiated  by  BLM  to  help 
identify  and  refine  its  ADP  requirements  for  various  programmatic  or 
functional  activities  within  the  Bureau.  They  address  automation  of  certain 
manual  processes  in  case/operations  processing,  land  and  resource  inventory 
and  analysis,  and  administrative  applications.  These  related  projects  and 
studies,  discussed  below,  are  being  coordinated  and  integrated  with  the 
overall  ADEMP  study. 

1.3.1  Automated  Land  and  Minerals  Record  System  (ALMRS) 

In  the  beginning  of  FY  1984,  the  Federal  Computer  Performance 
Evaluation  and  Simulation  Center  (FEDSIM)  was  tasked  by  BLM  to  conduct  a  study 
to  define  the  feasibility  of,  and  the  functional  requirements  for,  an 
automated  system  to  support  BLM  in  its  Lands  and  Minerals  and  Records  mission. 
Prior  to  the  FEDSIM  study,  an  established  ALMRS  team  had  produced  a 
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description  of  the  ALMRS  system  and  program,  an  initiation  phase  document,  a 
user  requirements  document,  and  a  draft  ALMRS  feasibility  study.  The  draft 
ALMRS  Feasibility  Study  was  accepted  as  final  in  April  1986.  The  information 
collected,  reviewed,  and  analyzed  for  this  study  was  provided  to  FEDSIM  by  the 
ALMRS  Project  Office. 

ALMRS  will  replace  the  Bureau's  current  Case  Recordation  System,  which 
does  not  meet  all  of  BLM's  case  processing,  management  reporting,  or  query 
requirements.  The  chief  objectives  of  this  initiative  are  to  improve  BLM's 
Lands  and  Minerals  management  capabilities  and  improve  productivity. 
Implementation  of  ALMRS  is  expected  to  save  labor  costs  (the  number  of  new 
hires  required  to  meet  the  projected  workload  will  be  reduced)  and  improve  the 
productivity  of  existing  labor;  improve  service  to  industry,  the  general 
public,  and  other  Federal  agencies  by  providing  faster  and  more  efficient 
application  and  query  processing;  and  improve  the  quality  of  BLM  decision 
making  by  providing  for  more  comprehensive  analysis.  It  is  the  largest  BLM 
application  identified  to  date. 

1.3.2  Geographic  Information  Systems  (GIS) 

The  Automated  Resource  Requirements  Study  (ARRS)  was  conducted  by  a 
BLM  team  to  identify  the  functional  requirements  and  workload  characteristics 
for  automating  the  resource  management  workload  of  the  Bureau.  Most  resource 
management  work  includes  spatial  analysis  and  graphics  (GIS)  as  well  as 
alphanumeric  data  storage  and  retrieval. 

BLM  currently  has  an  operational  GIS  capability,  which  has  been 
implemented  in  a  limited  number  of  BLM  sites.  A  combination  of  increased 
demand  for  more  accurate  and  complicated  resource  analysis  and  the  projected 
workload  led  the  BLM  team  to  the  conclusion  that  GIS  capabilities  must  be  made 
available  to  a  greater  number  of  users  to  more  effectively  support  agency-wide 
resource  management  activities.  The  long-term  functional  and  workload 
requirements  outlined  in  the  ARRS  study  will  be  incorporated  into  the  overall 
ADP  planning  effort. 
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1.3.3  Geographic  Coordinate  Data  Base  (GCD8)  Study 

8LM  has  documented  the  requirements  for  an  integrated  GCDB.  This 
data-base  will  eventually  store  coordinate  data  for  lands  under  BLM's 
jurisdiction  and  will  be  used  by  both  ALMRS  and  GIS  as  the  basis  of  locating 
discrete  latitude  and  longitude  coordinates  for  their  applications. 

1.3.4  Farmington  Demonstration  Project 

The  purpose  of  this  project,  initiated  in  March  1986,  is  to  evaluate 
alternative  concepts  for  integrating  records  (ALMRS),  resources  (GIS)  and 
geographic  coordinate  data  (GCDB)  into  a  Land  Information  System  (LIS). 
Through  testing  of  various  software  alternatives  in  an  operational 
environment,  functional  and  system  requirements  related  to  LIS  are  being 
refined.  Study  findings  will  be  incorporated  into  BLM's  overall  Modernization 
effort. 

1.3.5  Office  Automation 


BLM  currently  has  a  contract  with  WANG  Computers  to  support  the 
Bureau's  office  automation  needs.  This  contract  is  soon  to  expire.  Rather 
than  separately  re-compete  the  contract,  BLM  has  decided  that  office 
automation  should  be  part  of  the  overall  technical  architecture.  Requirements 
for  office  automation  are  currently  being  determined  by  BLM  and  will  be 
incorporated  into  the  ADEMP  project. 

1.3.6  Eastern  States  GLQ  Records  Project 

The  chief  goals  of  this  project  are  to  develop  an  automated  storage 
and  retrieval  system  for  the  Eastern  States  Office's  (ESO)  public  land  records 
and  to  ensure  that  this  public  land  data  can  be  easily  integrated  into  the 
ALMRS  application.  At  present,  BLM  eastern  and  western  offices  use  dissimilar 
methods  for  keeping  public  land  records.  ADEMP  will  address  the  ADP  resource 
needs  of  the  ESO  for  a  western  states-  and  ALMRS-compatible  public  land  and 
minerals  records  system. 


1-7 


1.4  Methodology,  Limitations,  and  Assumptions 

The  objectives  of  this  analysis  are  to: 

o  Refine  the  alternative  technical  architectures  to  those 

which  could  viably  meet  BLM's  needs.  The  resulting  set 
of  viable  alternatives  (those  options  which  could  meet 

BLM's  ADP  requirements)  will  be  costed  in  Task  8,  an 

Economic  Analysis. 

o  Review  and  assess  the  applicability  of  the  FIRMR 

identified  alternative  sources  (e.g. ,  expanding  system 
contracts  to  upgrade  individual  components,  timesharing, 
competitive  procurement,  etc.)  for  acquiring  the  ADP 
resources  required  and  provide  a  recommendation  for  the 
best  means  for  acquisition. 

o  Specify  the  operating  systems,  data  base  management 

systems,  application  programming  languages,  graphics,  and 
communications  standards  that  should  be  incorporated  into 
the  Modernization  hardware  and  system  software 
procurement. 

o  Identify  subsequent  steps  in  the  Modernization  project. 

The  acquisition  and  technical  architecture  alternatives  represent 
different  implementation  methodologies  to  provide  the  ADP  support  for  the 
functional  processes  required  by  BLM  to  accomplish  its  mission.  The  essence  of 
the  ADP  modernization  effort  is  to  provide  these  functional  capabilities  to  a 
geographically  dispersed  user  community  in  the  most  effective  way  possible 
with  commercially  available  ADP  technology. 

In  a  previous  deliverable.  Definition  of  Alternative  Concepts  for  the 
Bureau  of  Land  Management  ADP  Modernization  Project,  AMS  presented  BLM  with 
the  alternatives  for  meeting  its  needs  for  ADP  and  telecommunications  support 
and  a  brief  description  of  the  criteria  to  be  used  in  evaluating  these 
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alternatives.  The  objective  of  this  report  is  to  narrow  those  alternatives 
down  to  the  point  where  economic  factors  are  the  only  major  differentiating 
criteria. 

Our  approach  to  refining  both  sets  of  alternatives  (technical  architec¬ 
ture  and  acquisition)  was  to  identify  the  criteria  that  discriminate  most 
sharply  against  the  alternatives  and  evaluate  the  alternatives  with  respect  to 
these  criteria.  The  analysis  of  acquisition  alternatives  is  performed 
independently  of  the  analysis  of  technical  architecture  alternatives. 

The  central  issue  in  selecting  a  system  architecture  is  to  determine  the 
most  effective  way  to  distribute  the  control  and  physical  location  of  the 
system's  data.  Thus,  our  approach  to  developing  the  set  of  system 
architecture  alternatives  was  to  investigate  varying  degrees  of  data  base  and 
processing  distribution.  The  alternatives  range  from  a  highly  centralized 
architecture  in  which  the  data  base  storage  and  processing  are  performed  at 
one  location  to  a  distributed  architecture  in  which  processing  and  data 
storage  is  accomplished  at  the  end-user  locations.  While  the  implementation 
of  any  one  alternative  may  require  consideration  of  several  detailed  design 
approaches,  the  alternatives  presented  here  represent  the  general  range  of 
what  is  feasible  given  BLM's  functional  and  technical  requirements. 

In  developing  the  alternatives,  we  recognized  that  there  are  several 
automated  systems  which  must  be  integrated  into  the  overall  ADP  architecture. 
For  example,  BLM  intends  to  begin  design  and  construction  of  the  Automated 
Lands  and  Minerals  Records  Systems  (ALMRS)  before  the  contract  for  ADP 
equipment  from  the  ADP  Modernization  Study  is  awarded.  In  addition,  BLM  has 
major  efforts  underway  for  enhancement  of  its  Geographic  Information  Systems 
(GIS)  and  the  development  of  a  Geographic  Coordinate  Data  Base  (GCDB). 

This  report  does  not  specifically  address  hardware  sizing  as  it  is  not 
relevant  to  determining  viable  technical  architectures.  We  are,  however, 
finalizing  workload  data,  provided  by  BLM,  which  we  will  use  in  conjunction 
with  a  Workload  Analysis  Model  to  determine  required  system  sizing.  This 
information  will  be  used  in  preparing  Task  8's  Economic  Analysis. 
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1.5  Organization  of  this  Document 


In  addition  to  this  introduction,  this  document  is  divided  into  four 

chapters: 

o  Chapter  2,  Overview.  Chapter  2  summarizes  the 
conclusions  of  this  task  and  the  implications  for 
subsequent  tasks  of  the  ADP  Modernization  Project. 

o  Chapter  3,  Technical  Architecture  Alternatives.  Chapter 
3  presents  the  first  class  of  alternatives  requiring 
analysis:  those  relating  to  the  system  architecture 
itself.  Key  criteria  are  identified  and  alternative 
architectures  are  analyzed  with  respect  to  how  well  they 
meet  these  criteria.  Also  discussed  in  this  chapter  is 
the  level  of  computer  processor  specialization  required 
in  BLM's  technical  architecture. 

o  Chapter  4,  Acquisition  Alternatives.  Chapter  4 
identifies  the  alternative  sources  for  acquiring  the  ADP 
resources  for  BLM's  Modernization  effort.  Each 

alternative  is  evaluated  with  respect  to  how  well  it 
satisfies  some  key  factors,  which  are  also  defined  in 
this  chapter. 

o  Chapter  5,  Standards.  Given  the  constraint  that  hardware 
and  system  software  procurement  for  the  major  development 
efforts  underway  within  8LM  (e.g.,  ALMRS)  will  be 
initiated  prior  to  the  Modernization  procurement,  certain 
standards  for  system  software  were  decided  upon  in  order 
to  enable  coordination  between  efforts.  Chapter  5 
outlines  the  specific  areas  where  standards  were 
selected.  A  complete  discussion  is  presented  of  all 

alternatives  within  each  area. 
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o  Chapter  6,  Ensuing  Steps.  Chapter  6  outlines  additional 
issues  to  be  resolved.  The  Chapter  includes  a  brief 

discussion  of  the  Workload  Analysis  Model  which  will  be 
used  in  determining  required  CPU  capacity,  and  the 
Economic  Study  which  will  analyze  each  technical 
architecture  alternative  defined  in  this  report  (with  the 
results  of  the  Workload  Model  incorporated)  in  economic 
terms. 


2.0  OVERVIEW 


The  objective  of  the  ADEMP  project  is  to  conduct  relevant  studies  and 
analyses  to  identify  and  quantify  the  ADP  resources  needed  by  BLM  to  meet  its 
mission  objectives  and  provide  the  technical  specifications  which  will  result 
in  potential  vendors  proposing  the  most  effective  hardware,  system  software, 
support,  and  data  communications  solutions.  The  overall  goal  of  this  paper  is 
to  identify  those  alternative  technical  architecture  configurations  (i.e.,  in 
terms  of  computer  equipment,  systems  software,  and  data  communications 
equipment  and  system  support)  which  are  the  most  viable  for  BLM,  and  which  can 
then  be  costed  in  Task  8  -  the  Economic  Analysis.  Acquisition  and  software 
standards  issues  are  also  addressed  in  this  document. 

BLM's  objectives  for  ADP  played  a  major  role  in  determining  which 
acquisition  and  technical  architecture  alternatives  were  feasible. 

This  document  analyzes  the  technical  architecture  and  acquisition 
alternatives  available  to  BLM,  presents  a  discussion  of  the  software  standards 
agreed  upon  for  the  ALMRS  development  project  which  will  be  incorporated  into 
the  overall  Modernization  effort,  and  outlines  steps  for  further  evaluation. 

Based  on  our  analysis  to  date,  we  have  reached  the  following  conclusions: 

o  System  Architecture: 

The  key  determining  factors,  with  respect  to  physical  computer  and 
data  distribution,  are  the  cost  of  implementing  the  alternative 
configuration  and  management  and  control  of  the  hardware  and 
application  and  system  software.  The  refined  set  of  technical 
architecture  alternatives  identified  in  this  report  will  all  be 
costed  in  Task  8,  the  Economic  Analysis. 
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o  Acquisition: 

A  competitive  procurement  will  provide  the  best  means  for  acquiring 
the  ADP  and  data  communications  hardware  and  system  software  required 
for  the  Bureau's  ADP  Modernization.  No  other  alternative  analyzed 
can  provide  BLM  with  a  solution  that  will  satisfy  the  Bureau's 
requirements  for  flexibility,  integration  of  applications,  and 
compatibility  with  existing  systems. 

o  CPU  Specialization: 

If  specialized  computer  systems  (e.g.,  CPUs  with  array  processors  for 
more  efficient  numerical  computations)  are  included  in  BLM's  new 
technical  architecture,  their  use  must  be  transparent  to  the  users 
(i.e.,  a  user  will  not  have  to  provide  specific  instructions  while 
running  applications  with  respect  to  which  device  to  utilize).  In 
addition,  the  software  running  on  the  specialized  computer  systems 
must  be  fully  compatible  across  processors  (i.e.,  the  software  should 
be  able  to  run  on  any  combination  of -specialized  processors). 

Alternative  sources  analyzed  for  acquiring  the  ADP  resources  required  for 
BLM's  ADP  Modernization  were  those  identified  in  GSA's  Federal  Information 
Resources  Management  Regulations  (FIRMR)  in  section  201-30.009.  These 
included  alternatives  which  assume  the  current  systems  are  replaced  as  well  as 
those  which  assume  the  current  systems  are  not  replaced  (e.g.,  rearranging 
current  ADP  resources  to  improve  current  system  utilization).  AMS  categorized 
these  alternatives  into  three  categories.  These  included  alternatives 
involving  the  use  of  non-ADP  resources,  alternatives  involving  the  use  of 
other  sources  of  ADP  resources  to  augment  existing  capabilities,  and 
alternatives  involving  the  replacement  of  existing  systems.  Certain  key 
factors  such  as  flexibility,  integration  of  applications,  and  compatibility 
with  existing  systems  were  utilized  to  evaluate  the  alternatives  identified. 

The  next  area  addressed  in  this  document  concerns  the  technical 
architecture  itself.  Alternatives  for  the  physical  location  of  ADP  resources 
and  data  were  analyzed  with  respect  to  how  well  each  matches  BLM's 
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organizational  structure,  satisfies  BLM's  needs  for  flexibility  and 
reliability,  and  how  much  impact  the  technical  architecture  would  have  on  BLM 
staffing  and  organizational  structure.  The  alternatives  evaluated  vary  in  the 
extent  tox  which  each  relies  on  communications  technology.  The  level  of  CPU 
specialization  is  also  discussed  with  respect  to  the  type  of  computer  systems 
(e.g.,  general  purpose  or  specialized)  necessary  for  BLM  to  carry  out  its 
responsibilities  more  effectively. 

Representatives  of  the  BLM  IRM/TAC  committee.  Field  Committees,  and 
Division  of  Information  Resources  Management;  and  the  ALMRS  Project  Manager 
met  with  AMS  February  11-13,  1987  to  set  various  standards  for  the  ALMRS 
development  project.  The  purpose  of  this  meeting  was  to  decide  upon  operating 
systems,  spatial  graphics,  data  base  management  systems,  communications,  and 
language  standards  for  ALMRS.  The  objective  of  setting  these  standards  now 
was  to  enable  ALMRS  application  development  to  proceed  before  hardware  and 
system  software  vendors/products  have  been  selected  for  BLM's  overall 
Modernization  effort  while  reducing  the  risk  of  incompatibility  between  ALMRS 
and  the  new  technical  architecture.  A  review  of  this  meeting  is  presented  in 
this  paper. 

Our  next  task  is  to  determine  the  amount  of  computer  processing  capacity, 
based  on  the  specific  requirements  of  the  current  and  future  BLM  applications, 
that  will  be  required  to  support  BLM  in  carrying  out  its  mission.  Some  of 
these  statistics  have  already  been  compiled  and  a  preliminary  estimate  was 
presented  in  Task  3.  The  available  workload  statistics  at  that  time  were 
insufficient  for  compiling  a  quantitative  estimate  and  we  have  since  been 
gathering  additional  data  on  BLM's  current  and  future  workload.  AMS  will 
input  the  compiled  workload  statistics  into  a  Workload  Analysis  Model,  and  for 
each  alternative  technical  architecture  defined  in  this  document,  estimate  the 
required  CPU  size,  and  the  number  of  input/output  channels  and  disk  drives 
required  to  support  BLM's  workload.  The  results  of  this  analysis  will  then  be 
used  as  input  to  a  cost  model  to  determine  the  cost  for  each  technical 
architecture  alternative. 

Following  the  Economic  Analysis,  AMS  will  prepare  an  implementation  plan 
addressing  the  procurement  approach  for  the  technical  architecture,  the 
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overall  schedule  for  acquisition  and  implementation,  and  the  installation  and 
phase-in  approach.  In  conjunction  with  the  development  of  the  implementation 
plan,  AMS  will  complete  a  Preparation  of  Specifications  for  the  new  technical 
architecture  to  be  used  in  Section  C  of  the  Request  for  Proposals  for  the  BLM 
technical  architecture. 


3.  SYSTEM  ARCHITECTURE  ALTERNATIVES 


The  first  class  of  alternatives  requiring  analysis  involves  the  technical 
architecture  of  BLM's  ADF  system.  As  mentioned  in  the  Task  4  deliverable, 
there  are  two  issues  to  be  addressed  with  respect  to  system  architecture: 

o  Physical  Computer  and  Data  Distribution.  This  issue  refers 
to  the  distribution  of  computer  processors  and  data  storage 
facilities  throughout  BLM.  The  alternatives  for  organizing 
ADP  resources  differ  in  the  extent  to  which  each  relies  on 
communications  technology  and  end-user  computing  technology. 

At  one  extreme,  a  fully  centralized  system  can  be  envisioned 
that  enables  all  users  to  access  processing  and  data  base 

resources  residing  at  a  single  ADP  facility  (e.g.,  the  Denver 
Service  Center  (DSC))  via  terminals.  At  the  other  extreme,  a 
distributed  system  can  be  envisioned  in  which  all  BLM  offices 
have  their  own  ADP  facilities. 

o  CPU  Specialization.  This  issue  refers  to  the  types  of 
processors  to  include  in  the  system  configuration.  In 
addition  to  general-purpose  computers,  many  computers  are 
designed  to  be  more  efficient  processing  a  specific 

application  type  (e.g.,  scientific  or  administrative). 
Increased  specialization,  however,  can  also  complicate  ADP 
management  and  support.  Whether  or  not  specialized  computer 
systems  are  included  in  BLM's  new  technical  architecture,  the 
type  of  processors  in  the  configuration  should  be  transparent 
to  the  user. 

3.1  Physical  Computer  and  Data  Distribution 

The  location  of  the  nodes  where  BLM  data  are  stored  and  processed  is 

the  central  issue  in  determining  viable  AOP  architectural  alternatives.  The 
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initial  alternative  set  included: 

o  Fully  Centralized  (DSC) 

o  Centralized  (DSC)  plus  State  Offices 

o  Central  (DSC)  plus  State  Offices  plus  District  Offices 

o  Central  (DSC)  plus  State  Offices  plus  all  sites  with 
workload  over  a  pre-determined  factor 

o  All  sites 

o  Fully  distributed 

Although  many  different  variations  of  centralization  and  decentralization 
are  possible,  we  have  narrowed  the  "analysis  space"  down  (in  section  3.1.2)  to 
the  four  alternatives  we  believe  will  enable  the  Bureau  to  carry  out  its 
responsibilities  most  effectively  and  more  efficiently. 

This  section  describes  the  alternatives  available  to  BLM  for  physical 
computer  and  data  distribution,  why  we  recommend  elimination  of  the  fully 
centralized  and  fully  distributed  alternatives  from  those  identified,  the 
criteria  identified  for  evaluating  the  remaining  alternatives,  an  evaluation 
of  how  each  of  the  remaining  alternatives  satisfies  each  criterion,  and  a 
comparison  of  the  alternatives. 

The  analysis  in  this  section  is  based,  in  part,  on  ideas  presented  by 
Mudie  and  Schafer*.  They  outlined  a  methodology  for  determining  the 
optimal  processing  environment  for  an  organization  such  as  BLM,  where  flex¬ 
ibility,  responsiveness  to  change,  and  cost  effectiveness  are  important. 
Mudie  and  Schafer  classify  applications  by  two  factors:  application  type 
(e.g.,  production  processing,  decision  support,  and  office  systems)  and  scope 

*Mudie,  M.W.  and  Schafer,  D.J.  "An  Information  Technology  Architecture  for 
Change,"  IBM  System  Journal,  Vol.  24,  Nos.  3/4,  1985. 
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(e.g.,  organization-wide,  departmental,  single-user).  With  respect  to  BLM, 
departmental  system  characteristics  referred  to  in  their  paper  are  equivalent 
to  local  offices.  They  stress  the  need  for  a  technical  architecture  that  can 
adequately  support  the  needs  of  all  types  of  applications  (e.g.,  local  as  well 
as  organization-wide)  and  the  importance  of  the  appropriate  distribution  of 
ADP  control. 

3.1.1  Alternatives  for  Physical  Computer  and  Data  Distribution 

Six  architectural  alternatives  were  identified  for  initial 
consideration.  Each  represents  a  different  approach  to  meeting  BLM's 
operational  requirements.  Alternatives  have  been  developed  only  to  the  detail 
necessary  to  evaluate  the  overall  approach  in  terms  of  its  ability  to  meet  the 
functional  and  workload  requirements  identified  earlier  in  the  project.  This 
section  provides  a  description  of  the  alternatives.  The  key  criteria  by  which 
these  will  be  evaluated  are  presented  in  section  3.1.3. 

3. 1.1.1  Fully  Centralized 

A  fully  centralized  system  is  a  technical  architecture  utilizing  a 
large,  central  computer  facility  containing  most  of  the  computer  equipment 
(i.e.,  CPUs,  disk  drives,  tapes).  Some  I/O  devices  such  as  plotters, 
printers,  etc.  would  be  located  at  facilities  other  than  the  central  site. 
The  centralized  computer  facility  would  be  located  at  OSC.  Users  access  this 
central  facility  via  local  terminals  (or  PCs  emulating  terminals  —  more 
sophisticated  workstations  would  be  considered  part  of  a  decentralized 
configuration)  connected  to  the  central  facility  through  a  wide-area 
communications  network. 

Within  each  site,  terminals  would  be  connected  to  each  other  via  a  local 
communications  network.  This  local  network  would  include  a  gateway  to  the 
Wide  Area  Network. 

Computer  operations,  support  and  maintenance  would  be  concentrated  at 
OSC.  Software  development,  training,  and  hotline  support  would  most  likely 
also  be  concentrated  at  DSC,  (though  it  would  not  be  constrained  to  be 
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centrally  located  by  the  centralized  architecture) . 

All  interfaces  to  outside  systems  (e.g.,  U.S.  Geological  Survey,  the 
Bureau  of  Reclamation,  the  Forest  Service  and  the  Bonneville  Power  Administra¬ 
tion)  and  to  other  BLM  sites  would  be  performed  through  network  gateways  at 
DSC. 


3. 1.1.2  Centralized  (DSC)  Plus  State  Offices 


With  this  architecture,  a  centralized  computing  facility  would  be 
maintained  at  DSC  as  well  as  decentralized  computing  facilities  at  each  of 
BLM's  twelve  State  offices.  Each  State  office  would  have  sufficient  ADP 
resources  to  support  their  processing  requirements  as  well  as  those  of  their 
respective  District  and  Resource  Area  Offices  (who  will  also  be  able  to  access 
DSC). 

A  Wide  Area  Network  would  be  used  to  access  information  “local"  to 
another  field  office.  For  example,  sometimes  work  for  one  task  is  performed 
across  BLM  offices.  Data  may  be  created  in  one  office  which  another  office 
needs  for  processing.  This  second  office  would  use  the  distributed  processing 
capability  to  access  the  remote  data  (if  permitted). 

Within  each  District  and  Resource  Area  office,  terminals  would  be 
connected  to  each  other  and  the  Wide  Area  Network  through  a  Local  Communica¬ 
tions  Network.  The  Wide  Area  Communications  Network  will  provide  access  to 
the  remote  computing  capability  of  the  State  offices  in  DSC. 

The  Denver  Service  Center  would  continue  to  perform  BLM-wide 
administrative  functions,  and  would  have  sufficient  disk  and  processing 
capacity  to  satisfy  its  needs. 

The  size  of  the  State  Office  computers  may  vary  in  accordance  with  the 
processing  requirements  of  each  State  and  its  corresponding  District  and 
Resource  Area  Offices.  Each  computer,  however,  will  be  compatible  at  the 
object  code  and  operating  system  level.  This  would  allow  BLM  to  achieve 
transparent  software  portability  (the  ability  to  move  program  source  code  from 
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one  computer  to  another,  without  conversion,  and  have  that  code  execute  to 
produce  identical  results  on  each  computer).  This  permits  reduction  or 
potential  elimination  of  the  cost  of  converting  software  from  one  machine  to 
another,  it  gives  BLM  the  flexibility  to  install  applications  on  computers  of 
the  appropriate  size  and  power  for  each  office  without  developing  multiple 
implementations  of  the  same  application. 

3. 1.1.3  Centralized  Plus  State  Offices  Plus  District  Offices 


This  architectural  alternative  is  similar  to  the  one  above  with  the 
exception  that  computing  resources  will  also  be  located  in  District  Offices. 

3. 1.1.4  Centralized  Plus  State  Offices  Plus  All  Sites  With  Workload  Over  a 
Pre-determined  Factor 


In  this  technical  architecture,  separate  computer  systems  would  be 
located  at  DSC,  State  Offices,  and  each  District  or  Resource  Area  Office  with 
more  than  a  pre-determined  workload.  Under  this  alternative,  a  specific 
cut-off  point  for  Installing  ADP  resources  at  a  site  would  be  defined.  Each 
site  whose  workload  qualifies  them  for  on-site  computing  capabilities  would 
have  the  ADP  resources  required  to  support  both  its  needs  and  the  needs  of  any 
"subordinate"  or  "peer"  office(s)  that  will  be  accommodated  by  its  system. 

A  Wide  Area  Network  would  be  used  to  access  information  residing  on 
remote  computers.  DSC  would  still  have  responsibility  for  providing  BLM-wide 
administrative  functions  and  ADP  support  and  would  have  sufficient  computer 
resources  for  its  ADP  needs. 

Within  each  site,  terminals  would  be  connected  via  a  local  communications 
network.  For  those  sites  with  a  computer,  this  network  would  provide  users 
access  to  the  local  computing  resources.  For  those  sites  without  a  computer, 
the  Local  Communications  Network  would  provide  access  to  the  Wide  Area 
Network,  which  would,  in  turn,  allow  users  access  to  the  remote  computing 
facilities  of  higher  offices. 
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As  in  the  previous  two  alternatives,  the  size  of  the  individual  computer 
systems  would  vary  in  accordance  with  the  workload  of  the  site.  Each  computer 
system  would  be  compatible  so  application  and  development  software  and  data 
can  be  shared  among^BLM  offices. 

All  interfaces  to  outside  systems  and  to  other  BLM  sites  would  be 
performed  through  the  Wide  Area  Network. 

3. 1.1.5  All  Sites 


Within  this  architecture,  decentralized  computer  systems  would  be 
located  in  each  Resource  Area,  District,  and  State  Office;  DSC;  BIFC;  and  the 
BLM  headquarters  in  Washington,  D.C.  Each  computer  system  would  have 
sufficient  processing  and  storage  capacity  to  process  all  local  applications 
(i.e.,  development  of  a  Resource  Management  Plan  (RMP)  by  a  Resource  Office). 

DSC  would  continue  to  provide  BLM-wide  administrative  functions,  and 
would  have  computer  resources  sufficient  for  its  needs. 

« * 

Within  each  site,  terminals  would  be  connected  to  each  other  and  the 
local  computer  via  a  Local  Area  Communications  Network.  The  separate  computer 
systems  would  be  connected  via  a  Wide  Area  Network,  accessed  through  a  gateway 
from  the  individual  Local  Area  Networks. 

As  with  the  preceding  three  alternatives,  the  size  of  the  computers 
installed  at  each  location  would  vary  in  accordance  with  the  ADP  requirements 
(workload)  of  each.  AMS  assumes  that  co-located  offices  will  combine  their 
computing  requirements  into  a  single,  larger  system.  (Certain  co-located 
field  offices  may,  when  the  systems  are  implemented,  require  separate  systems 
with  separate  access,  control,  and  management.)  All  computers  will  be 
compatible  to  facilitate  sharing  of  applications  and  development  software  and 
data. 


All  interfaces  to  outside  systems  and  to  other  BLM  sites  would  be 
performed  through  the  Wide  Area  Network. 
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3. 1.1.6  Fully  Distributed  (No  DSC) 

This  architecture  alternative  is  similar  to  the  "All  Sites" 
alternative  except  that  there  would  be  no  central  computing  facility  at  DSC  to 
provide  BLM-wide  administrative  functions.  However,  there  would  be  a  computer 
at  DSC  to  support  DSC's  own  financial  and  personnel  systems. 

3.1.2  Physical  Computer  and  Data  Distribution  Alternatives  Eliminated  From 
Further  Consideration 


Of  the  six  alternatives  outlined  in  the  previous  section  four  are 
recommended  for  detailed  analysis.  We  recommend  the  elimination  from 
consideration  of  the  alternative  of  a  centralized  ADP  facility  as  well  as  the 
option  involving  the  elimination  of  the  Denver  Service  Center.  One  of  the 
major  points  of  the  Mudie  and  Schafer  paper  is  the  importance  of 
differentiating  between  organizations  that  are  geared  towards  end-user 
computing  and  those  geared  towards  traditional  data  processing  activities. 
They  concluded  that  for  organizations  which  are  geared  toward  end-user 
computing,  ADP  resources  should  be  distributed  because,  in  general,  the 
greater  the  degree  of  ADP  decentralization,  the  greater  the  potential  that  the 
special  information  needs  of  the  different  user  groups  will  be  met.  Within 
BLM,  the  emphasis  is  on  end-user  computing:  most  of  the  data  is  collected  and 
used  in  the  field  offices  and  analysis  of  this  data  provides  the  basis  for  the 
Bureau's  day-to-day  operations.  Neither  of  the  two  alternatives  eliminated 
can  provide  a  good  "fit"  for  BLM. 

3. 1.2.1  Fully  Centralized 


BLM  is  a  large  organization  with  well-defined  subunits  and  a 
decentralized  management  philosophy.  The  Bureau  is  divided  into  four  levels 
(the  Washington  Office,  12  State  Offices,  approximately  50  District  Offices, 
and  about  160  Resource  Area  Offices)  and  each  level  of  the  organization  has 
distinct  responsibilities  in  implementing  BLM's  programs.  An  information 
system  structure  should  be  chosen  that  is  consistent  with  the  strategy, 
structure,  and  style  components  of  the  organization.  If  these  components  of 
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the  organization  are  ignored,  two  resulting  effects  significantly  increase 
risk: 

o  Different  management  structure,  styles,  and  objectives  will 
potentially  increase  conflict  and  confusion  resulting  in 
decreasing  ADP  support  capabilities/effectiveness. 

o  Resistance  to  change,  present  in  any  organization,  is  increased 

o  Factors  which  positively  effect  innovation  are  more  likely  to  be 
omitted 

These  effects  are  further  discussed  below: 

The  fully  centralized  option  would  greatly  increase  the  inherent 
resistance  to  change.  In  a  paper  published  by  the  Center  for  Information 
Systems  Research  in  the  Sloan  School  of  Management  at  the  Massachusetts 
Institute  of  Technology  ,  the  researchers  found  that  in  successful  companies, 
data  was  managed  from  -a  business  perspective,  rather  than  a  technical 
viewpoint.  That  is,  physical  distribution  of  data  resources  were  justified  by 
compelling  business  needs  (e.g. ,  coordination,  flexibility)  rather  than  by 
technical  arguments.  In  BLM,  each  State  Office,  with  its  associated  District 
and  Resource  Area  Offices,  function,  in  large,  as  separate  units.  The 
District  and  Resource  Area  Offices  are  responsible  for  administering  resource 
management  programs  for  land  and  mineral  resources  for  different  portions  of 
the  geographical  area  under  the  jurisdiction  of  their  associated  State  Office. 
The  Resource  Area  Offices  report  to  the  District  Offices  which,  in  turn, 
report  to  the  State  Offices.  The  authors  stressed  that  the  "recognition  of 
the  almost  inevitable  resistance  to  the  implementations  of  actions  which  shift 
real  or  perceived  power"  in  a  organization  is  of  the  utmost  importance.  Since 
each  State  Office  has  full  responsibility  for  the  lands  within  its 
jurisdiction,  they  should  also  be  given  responsibility  for  control  over  their 
data,  applications,  and  hardware.  So,  even  though  a  centralized  information 

_ 

cGoodhue,  D.,  Quillard,  J.,  Rockert,  J.,  "The  Management  of  Data:  Preliminary 
Research  Results",  Center  for  Informations  Systems  Research,  Massachusetts 
Institute  of  Technology,  May,  1986. 
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structure  is  technically  feasible,  it  would  not  provide  a  good  "fit"  for  the 
agency. 

Another  important  factor  cited  in  the  MIT  paper  that  led  AMS  to  the 
conclusion  that  a  centralized  ADP  facility  was  not  an  acceptable  alternative 
involves  innovation.  As  a  Federal  Agency,  BLM  is  ultimately  responsible  to 
the  public  for  its  management  of  the  Federal  lands  and  resources  within  its 
jurisdiction.  Innovations  (e.g.,  taking  advantage  of  the  latest  technologies) 
which  allow  the  Bureau  to  carry  out  its  responsibilities  in  the  most  efficient 
and  cost  effective  way  possible  will  be  simpler  and  involve  less  risk  if 
incorporated  within  a  distributed  technical  architecture.  The  researchers 
cite  several  factors  upon  which  successful  diffusion  of  innovation  is 
dependent.  Among  them  are  the  observability  of  results  (i.e.,  benefits)  and 
the  trialability  or  extent  to  which  the  innovation  can  be  experimented  with  on 
a  small  scale,  .  low  risk  basis.  With  a  fully  centralized  technical 
architecture,  any  innovation  would  most  likely  require  a  major  financial 
investment  by  BLM  and  "top  to  bottom"  commitment  in  the  Bureau  to  achieve 
results.  With  a  distributed  technical  architecture,  a  State  Office  may 
experiment  with  the  latest  state-of-the-art  technology  (e.g.,  a, new,  high 
density  storage  device),  or  implement  a  new  application.  This  innovation 
could  then  be  implemented  (or  not)  at  other  sites  based  upon  its  success  (or 
failure) . 

Since  the  clear,  tangible  advantages  of  a  centralized  system  over  other 
alternatives  are  few,  and  the  risk  substantially  higher,  the  fully  centralized 
alternative  should  not  be  considered  further. 

3. 1.2.2  Fully  Distributed  (No  DSC) 

The  alternative  involving  the  elimination  of  the  Denver  Service 
Center  is  also  not  in  the  best  interests  of  BLM.  There  are  obvious  advantages 

-3 

of  including  a  centralized  ADP  facility  in  BLM's  technical  architecture  . 
— 

King,  J.L,  and  Kraemer,  K.L.,  "Centralization  Versus  Decentralization  of 
Computer  Operations",  Computers  in  Local  Government.  Auerbach  Publishing, 


Inc.,  Vol.  3.1.5,  pp.  1-10,  1985 
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These  include  economies  of  scale,  sophistication  of  the  systems  environment, 
quality  of  systems  development,  and  ADP  cost  control. 

A  common  set  of  automated  capabilities  are  required  to  support  many  of 
BLM's  functions.  There  are  approximately  60  Bureau-wide  applications  used  by 
BLM  offices  across  the  country  (e.g.,  the  Financial  Management  System,  the 
Range  Management  Automated  System,  the  Case  Recordation  System).  DSC  provides 
consolidated  administrative  support  to  all  BLM  offices  and  is  also  responsible 
for  developing  new  scientific  and  technological  systems  for  use  in  BLM 
offices.  By  providing  BLM  with  a  central  data  processing  capability,  BLM  can 
recognize  the  economies  of  scale  resulting  from  the  sharing  of  resources. 
There  are  problems  currently  because  many  automation  efforts  are  not  shared 
enough.  For  example,  AOP  coordinators  in  some  states  were  not  aware  of  the 
work  being  done  in  other  States.  This  results  in  a  lot  of  duplication  in 
effort.  A  fully  distributed  structure  would  only  exacerbate  these  problems. 

3.1.3  Evaluation  Criteria  for  CPU  Distribution 


This  section  presents  the  criteria  by  which  the  alternative  hardware 
architectures  will  be  evaluated.  Several  criteria  were  outlined  in  Chapter  5 
of  Task  4,  Definition  of  Alternative  Concepts.  Certain  of  these  criteria  are 
most  important  to  the  objective  of  the  ADP  modernization  effort  and  thus  are 
used  to  evaluate  the  alternatives  for  the  physical  computer  and  data 
distribution.  These  includes 

o  Matching  configuration  design  to  organizational  design 
o  Flexibility 
o  Reliability 
o  Staffing  Impact,  and 


o  Organizational  Impact 
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3-1. 3.1  Matching  Configuration  Design  to  Organizational  Design 

A  computerized  information  system  design  that  is  chosen  to  be 
consonant  with  the  strategy,  structure,  and  style  components  of  an 
organization  can  be  expected  to  enable  an  organization  to  carry  out  Its 
responsibilities  more  effectively.  As  mentioned  in  section  3. 1.2.1,  the 
ultimate  goal  of  the  technical  architecture  is  to  link  ADP  resources  with  the 

needs  of  the  agency.  Matching  the  configuration  capabilities  to  the 
organizational  structure  is  an  important  factor. 

BLM  s  organizational  structure  and  management  style  is  decentral ized. 
Most  of  the  Bureau's  personnel  and  essentially  all  of  its  operations  are 
located  in  field  offices.  There  are  12  State  Offices,  each  with 
responsibility  for  land  in  one  to  three  states  (with  the  exception  of  the 
Eastern  States  Office  which  is  responsible  for  more  than  30  states).  Each 
State  Office  is  supported  by  between  two  to  ten  District  Offices,  which  in 
turn  oversee  a  variable  number  of  Resource  Area  Offices.  Most  direct 
operational  functions  are  performed  at  the  District  and  Resource  Area  levels. 


In  addition  to  its  State,  District,  and  Resource  Area  Offices,  BLM  also 
maintains  a  service  center  in  Denver,  Colorado  and  has  administrative 
responsibility  for  the  Boise  Interagency  Fire  Center. 

BLM's  environment  is  extremely  heterogeneous.  The  Bureau's  field  offices 
vary  substantially  in  size  and  emphasis.  In  addition,  different  programs  are 
emphasized  in  each  State  Office  (and  therefore  their  associated  District  and 
Resource  Area  Offices)  depending  on  the  resources  found  on  the  land  they 

manage.  For  example,  Colorado  emphasizes  minerals  programs,  while  Oregon 
emphasizes  forestry  programs. 

The  technical  architecture  must  allow  local  (e.g..  State  Offices, 
District  Offices)  users  control  over  their  data  and  applications.  Matching 
the  physical  distribution  to  the  organization  is  not  synonymous  to  matching 
control  to  the  organization.  Theoretically,  any  configuration  is  capable  of 
providing  the  necessary  control  given  the  correct  policies.  In  practice 
though,  this  tends  not  to  work  —  unless  there  is  a  very  strong  central 
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management  coupled  with  a  general  homogeneous  organization  mission  or 
environment.  To  the  end-user,  the  environment  in  which  he  works  would  appear 
similar  regardless  of  whether  the  ADP  resources  were  local  or  remote  as  long 
as  the  remote  system  was  designed  to  ^ensure  remote  users  appropriate  and 
adequate  control  over  their  required  ADP  resources.  But,  if  an  organization 
could  not  obtain  the  control  required  by  its  users  with  a  more  centralized 
approach,  then  the  physical  parallelism  (and  thus  a  more  distributed  approach) 
to  the  organizational  structure  is  necessary. 

3. 1.3.2  Flexibility 

Flexibility  refers  to  the  capability  of  a  resource  to  change  or 
adjust  to  satisfy  changes  in  users'  requirements.  Factors  such  as  greater 
than  anticipated  growth  in  user  interaction  and  the  inability  to  accurately 
estimate  workload  because  of  the  unavailability  of  system  workload  statistics 
make  this  a  very  critical  criteria.  For  example,  if  an  office  needs  more/less 
computing  power  than  originally  planned  for,  BLM  must  be  able  to  incorporate 
larger/smaller  computer  systems  into  the  configuration. 

3. 1.3.3  Reliability 


Reliability  refers  to  the  availability  of  a  resource  and  the  degree 
to  which  that  resource  performs  its  functions  in  the  manner  expected.  Users 
must  be  able  to  access  the  ADP  capabilities  and  complete  their  work  in  a 
timely  manner. 

In  addition,  software  versions  of  applications  and  operating  systems  must 
be  consistently  maintained  Bureau-wide.  Hardware  and  software  problems  must 
also  be  quickly  resolved.  Although  part  of  the  flexibility  criteria,  the 
availability  of  resources  to  meet  user  demand  also  effects  reliability  —  if 
services  are  not  available  as  needed,  then  the  system  is  not  reliable. 

3. 1.3.4  Staffing  Impact 


Automation  requires  support  of  many  kinds:  software  development, 
hardware  and  software  maintenance,  operations,  data  entry  and  validation. 
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planning,  user  support,  and  countless  other  tasks.  The  staff  needed  for  these 
tasks  will  change  with  the  hardware  architecture  implemented. 

Any  BLM  office  with  a  computer  system  must  have  the  appropriate  personnel  \ 
necessary  for  supporting  that  computer  system  and  its  applications.  The 
choice  of  a  system  architecture  must  take  into  account  the  level  of  support 
needed  to  operate  and  support  that  alternative.  A  key  factor  in  determining 
the  staffing  requirements  is  the  skill  level  of  the  personnel  who  will  be 
maintaining  the  system.  Staff  must  be  trained  in  the  operation  and 

maintenance  of  the  system.  In  addition,  users  must  be  trained  to  use  the  new 
system.  The  time  required  by  personnel  in  the  field  to  perform  necessary  ADP 
functions  will  differ  with  each  architectural  alternative.  At  some  low  level 
of  computerization  (e.g.,  micro-  or  supermicro-  computers  installed  in  small 
field  offices),  it  is  possible  that  ADP  maintenance  and  support  may  be  handled 
as  a  collateral  duty.  Staffing  requirements  will  increase  with  the  level  of 
computerization. 

BLM  currently  manages  ADP  and  telecommunications  out  of  the  Denver 
Service  Center  and  State -Off ices.  Changes  in  the  configuration  may  effect  the 
current  ADP  organization.  Even  with  a  distributed  ADP  architecture,  BLM  will 
still  need  a  user  hotline,  communications  specialists,  etc.  to  isolate  and 
resolve  any  technical  problems  beyond  the  scope  of  the  local  operators. 

For  any  technical  architecture  alternative,  the  precise  staffing  impact, 
in  terms  of  number  of  staff  required,  can  only  be  determined  based  upon  the 
complexity  of  BLM's  current  and  future  applications,  the  complexity  of  the 
selected  operating  environment,  and  (in  some  cases)  the  ability  of  the 
existing  staff  to  accept  collateral  duties. 

3. 1.3. 5  Organizational  Impact 

Organizational  changes  or  staffing  requirements  will  vary  depending 
upon  the  architectural  alternative.  Training  in  the  use  and  maintenance  of 
the  new  technical  architecture  will  require  a  large  amount  of  personnel 
resources.  Configuration  management  will  be  regulated  at  different  levels 
within  BLM  depending  on  the  physical  distribution  of  computing  resources. 
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Management  support  of  the  hardware  and  software,  from  a  centralized 
perspective,  will  also  change  based  upon  the  technical  architecture. 

3.1.4  Evaluation  of  Physical  Computer  and  Data  Distribution  Alternatives 

The  set  of  alternatives  remaining  to  be  analyzed  include: 

o  Alternative  1  -  Centralized  (DSC)  plus  State  Offices 

o  Alternative  2  -  Central  (DSC)  plus  State  Offices  plus 

District  Offices 

o  Alternative  3  -  Central  (DSC)  plus  State  Offices  plus  all 
sites  with  workload  over  a  pre-determined  factor 

o  Alternative  4  -  All  sites 

In  the  remainder  of  this  section,  each  of  the  above  alternatives  will  be 
evaluated  with  respect  to  how  well  each  satisfies  the  criteria  presented  in 
the  preceding  section.  Figure  3-1  summarizes  how  well  each  of  these 
alternatives  satisfies  each  criterion. 

3. 1.4.1  Alternative  1  -  Centralized  (DSC)  plus  State  Offices 

The  physical  distribution  of  ADP  resources  under  this  alternative 
would  not  mirror  the  physical  organization  of  the  Bureau.  Most  BLM  operations 
are  performed  in  District  and  Resource  Area  Offices.  For  example.  District 
Offices  are  the  primary  level  for  economic  and  geological  analysis,  and 
Resource  Area  Offices  are  the  primary  level  for  the  data  collected  for  BLM  to 
use  in  carrying  out  its  mission.  State  Offices  primarily  provide 
administrative  services  to,  and  monitoring  the  work  of,  these  District  and 
Resource  Area  Offices. 

The  flexibility  and  reliability  of  this  alternative  is  dependent  upon 
both  the  specific  equipment  and  software  originally  installed  and  commitment 
of  ADP  staff  to  maintain  the  types  and  levels  of  resources  required  by  users. 
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FIGURE  3- 1 

A  Technical  Architecture  Extending  to  All 
Sites  Best  Satsifies  the  Criteria 
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Placement  of  BLM  staff  would  not  be  affected  by  a  configuration  with  ADP 
facilities  at  DSC  and  the  State  Offices.  This  alternative  mirrors  the  current 
ADP  configuration. 

3. 1.4.2  Alternative  2  -  Central  (DSC)  plus  State  Offices  plus  District 
Offices 


This  alternative  configuration  would  only  partially  meet  the  criteria 
for  matching  configuration  design  to  organizational  design.  Although  ADP 
facilities  would  be  extended  to  another  level  in  BLM  where  work  is  performed, 
those  offices  where  significant  portions  of  the  daily  operational  functions 
are  performed  (Resource  Areas)  will  not  have  on-site  processing  capabilities. 
As  a  result,  these  locations  would  not  have  direct  control  over  their  data  and 
appl i cations. 

As  with  the  previous  alternative,  the  flexibility  and  reliability  of  this 
alternative  is  dependent  upon  both  the  specific  equipment  and  software 
originally  installed  and  the  commitment  of  the  ADP  staff  to  maintain  the  types 
and  levels  of  resources  required  by  users. 

Any  field  office  with  a  computer  system  must  have  the  appropriate 
personnel  necessary  for  supporting  that  computer  system  and  its  applications. 
At  some  low  level  of  computerization  (e.g.,  micro-  or  supermicro-  computers 
installed  in  small  field  offices),  it  is  possible  that  ADP  maintenance  and 
support  may  be  handled  as  a  collateral  duty.  Staffing  requirements  will 
increase  with  the  level  of  computerization.  Additional  staff  may  also  be 
necessary  for  management  and  software  distribution  since  there  will  be  more 
sites  at  which  to  install  and  maintain  software  (e.g.,  applications, 
communications,  operating  system  software  upgrades). 

As  system  size  and  complexity  increases,  the  level  of  support  required 
also  increases,  resulting  in  a  need  for  FTE  staff.  The  exact  size  and 
complexity  of  the  system  requiring  dedicated  support  is  dependent  upon  the 
precise  hardware,  software,  communications,  and  functions  performed. 
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3. 1.4.3  Alternative  3  -  Central  (DSC)  plus  State  Offices  plus  All  Sites  With 
Workload  Over  a  Pre-determined  Factor 


This  alternative  configuration  would  also  be  partially  (although  more 
so  than  Alternative  2)  consistent  with  BLM's  structure.  There  would  still  be 
offices  within  the  Bureau  that  perform  daily  operational  functions  that  would 
not  have  resident  data  processing  resources. 

The  flexibility  and  reliability  of  this  alternative  is  dependent  upon 
both  the  specific  hardware  and  software  originally  installed  and  the 
commitment  of  the  ADP  staff  to  maintain  the  types  and  levels  of  resources 
required  by  users. 

In  general,  the  more  distributed  the  technical  architecture,  the 
increased  requirement  for  support  staff.  While  a  full  FTE  would  not  be 
required  at  a  small  site  with  a  simple  computer  system,  maintenance  and 
operation  of  the  computer  system  would  be  at  least  a  significant  daily 
collateral  duty.  Management  support  of  the  hardware  and  software  will  have  to 
be  extended  to  all  field  offices  to  ensure  system  compatibility  (e.g.,  that 
all  systems  are  running  the  same  application  and  operating  system  versions  so 
data  and  applications  are  portable). 

The  ability  to  assign  support  as  a  collateral  duty  is  complicated  within 
BLM  by  the  fact  that  most  field  personnel  are  not  available  at  the  office 
location  on  a  regular  basis. 

3. 1.4.4  Alternative  4  -  All  sites 


This  alternative  meets  the  criterion  of  matching  the  physical 
organization  of  ADP  resources  to  structural  organization  of  BLM's  personnel 
resources.  As  mentioned  previously,  work  is  performed  at  all  levels  of  the 
organization. 

As  with  the  above  two  alternatives,  the  flexibility  and  reliability  is 
dependent  upon  the  capabilities  of  the  actual  equipment  and  software  acquired 
and  the  ability  of  BLM  to  continue  to  support  users'  needs. 
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3.1.5  Comparison  of  Alternatives 

Each  of  the  above  alternatives  have  the  potential  to  meet  BIM's  ADP 
support  requirements.  The  flexibility  of  any  configuration  is  dependent  upon 
the  characteristics  (e.g.,  how  easy  it  is  to  reconfigure  the  architecture)  of 
the  system,  not  on  the  placement  of  the  "pieces"  that  make  up  the  system. 

Staffing  will  also  depend  on  the  particular  system  installed.  Economies 
of  scale  for  maintenance  and  support  may  be  realized  if  the  technical 
architecture  included  only  OSC  and  State  Offices.  The  ADP  operations  support 
required  would  be  greater  for  a  greater  number  of  ADP  facilities  .  However, 
it  is  possible  that  some  of  the  computing  facilities  will  not  require  a 
dedicated  staff  of  operators.  In  small  offices  with  a  simple,  easy  to 
maintain  computer  system,  for  example,  the  users  may  be  able  to  operate  and 
support  the  system  as  a  significant  daily  collateral  duty.  The  more 
distributed  the  architecture,  however,  the  more  staff  required  to  coordinate 
and  control  operations  (e.g.,  software  distribution  to  ensure  that  all  systems 
have  compatible  capabilities,  software  updates,  etc.).  Regardless  of  the 
extent  of  distribution,  a  core  of  technical  specialists  will  be  required  to 
isolate  and  resolve  any  complex  problems.  The  number  of  these  individuals 
required  should  increase  as  the  level  of  decentralization  of  processing 
resources  increases. 

3.1.6  Summary  and  Recommendation  for  Physical  Computer  and  Data 

Distribution  Analysis 

One  of  the  key  requirements  for  BLM's  technical  architecture  is  to 
allow  local  (e.g..  State  Offices,  etc.)  users  control  over  their  data  and 
applications.  Each  location  must  have  appropriate  and  adequate  computing 
power  available.  The  conceptual  ADP  system  must  be  consonant  with  the 
strategy,  structure  and  style  components  of  BLM.  This  does  not  necessarily 
mean  the  physical  distribution  of  the  ADP  system  must  mirror  the  physical 
distribution  of  BLM  staff.  Thus,  the  key  issue  with  respect  to  the  physical 
computer  and  data  distribution  is  the  desired  level  and  amount  of  control 
obtained  within  each  architectural  alternative.  Theoretically,  the  same 
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amount  of  control  should  be  obtainable  regardless  of  the  extent  of 
distribution  of  the  technical  architecture.  A  physical  parallelism  is  only 
necessary  if  the  level  of  control  required  cannot  be  provided. 

The  key  factor,  for  determining  configuration  design,  will  be  the  cost  of 
implementing  each  alternative.  A  more  centralized  approach  may  require  less 
computer  equipment,  but  will  also  require  faster,  and  more  reliable 
telecommunications  as  well  as  additional  centralized  and  distributed  support 
staff.  All  the  costs  involved  will  be  analyzed  in  depth  in  Task  8,  the 
Economic  Analysis  of  Alternative  Configurations. 

3.2  CPU  Specialization 


The  degree  of  CPU  specialization  necessary  for  effectively  supporting 
BLM's  ADP  needs  should  be  addressed  by  the  vendors  responding  to  the  RFP. 
AMS'  view  is  that  the  type  of  processors  incorporated  into  BLM's  new  technical 
architecture  should  be  transparent  to  the  users,  regardless  of  whether  or  not 
specialized  computer  systems  are  included.  All  elements  of  BLM's  ADP 
structure  must  interact  effectively  and  complement  one  another  in  order  to 
successfully  deliver  the  capabilities  needed  to  support  BLM  activities. 

GIS  applications  and  data  files  must  be  compatible  with  ALMRS  applications 
and  data  files.  Both  the  scientific  (GIS)  and  administrative  (ALMRS)  data 
must  be  interfaced  to  perform  comprehensive  analysis  and  reporting  on  the 
lands  managed  by  BLM. 

It  is  probable  that  some  degree  of  specialization  will  be  necessary  for 
these  applications  due  to  the  sophistication  of  the  numerical  computations  in 
GIS  analyses.  BLM  is  currently  using  specialized  computers  (i.e.,  CPUs  with 
array  processors)  for  GIS  processing.  The  key  point  with  respect  to 
specialization  is  that  any  specialized  computer  systems  incorporated  must  be 
fully  integrated  with  any  other  computer  systems  within  BLM's  new  technical 
architecture.  The  use  of  specialized  processors  must  be  transparent  to  the 
user.  In  addition,  the  software  for  these  specialized  machines  must  be  fully 
compatible  across  all  specialized  processors  —  that  is,  the  software  should 
be  able  to  run  (without  modification)  on  any  combination  of  specialized 
processors  (e.g.,  specialized  computers  of  different  sizes). 
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4.  ACQUISITION  ALTERNATIVES 


The  second  class  of  alternatives  requiring  analysis  involves  the  method 
of  acquisition  of  the  required  ADP  capabilities.  Alternative  sources  for 
acquiring  the  ADP  resources  required  are  identified  in  the  General  Services 
Administration's  Federal  Information  Resources  Management  Regulation  (FIRMR) 
in  section  201-30.009.  These  alternatives  include  both  those  which  assume  the 
current  systems  are  not  replaced  and  those  which  assume  replacement  of 
existing  systems.  Potential  sources  identified  for  analysis  are  categorized 
by  AMS  as: 

o  Use  of  non-ADP  resources 

o  Use  of  other  sources  of  ADP  resources  to  augment  existing 
capabilities,  and 

o  Replacement  of  the  current  ADP  systems 

This  chapter  describes  the  acquisition  alternatives  available  to  BLM  for 
the  procurement  of  ADP  equipment,  the  criteria  identified  for  evaluating  the 
alternatives  defined,  an  evaluation  of  how  well  each  alternative  satisfies 
each  criterion,  a  comparison  of  alternatives,  and  our  recommendations  for 
acquiring  the  ADP  resources. 

4.1  Acquisition  Alternatives 

The  alternatives  presented  in  this  section  were  identified  by  AMS  in 
our  Definition  of  Alternative  Concepts  for  the  Bureau  of  Land  Management  ADP 

Modernization  Project,  delivered  to  BLM  August,  1986.  These  alternatives 
correspond  to  those  specified  in  the  FIRMR.  For  the  readers  convenience,  they 
are  re-presented  below. 
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4.1.1  Use  of  non-AOP  Resources 

The  non-ADP  alternatives  available  to  BLM  are  summarized  into  three 

areas: 

o  Rearranging  current  ADP  resources  to  improve  system 

utilization 

o  Developing  improved  manual  procedures  to  reduce  the  need 
for  ADP  support,  and 

o  Combining  improved  system  utilization  with  improved 

manual  procedures 

Rearranging  the  current  ADP  resources  includes  activities  such  as 
revising  the  production  schedule  or  job  stream  to  improve  computer 
utilization,  balancing  data  storage  to  maximize  the  accessibility  of  disk 
space,  and  archiving  old  files  to  provide  additional  disk  space. 

Developing  improved  manual  procedures  to  reduce  the  need  for  ADP  support 
includes  redesign  of  existing  ADP  procedures  and  development  of  new  procedures 
so  that  reliance  on  the  computer  system  is  reduced. 

Combining  improved  system  utilization  with  improved  manual  procedures 
involves  both  rearranging  current  ADP  resources  to  improve  system  utilization 
and  developing  improved  manual  procedures  (e.g.,  adding  or  changing  shifts  to 
increase  capacity).  Rearrangement  of  resources  will  improve  the  system's 
ability  to  process  a  given  system's  workload  and  improved  manual  procedures 
will  focus  system  resources  where  they  are  needed  most. 

4.1.2  Use  of  Other  Sources  of  ADP  Resources  to  Augment  Existing  Systems 

BLM  has  several  acquisition  alternatives  which  use  other  sources  to 
augment  existing  system's  capabilities.  These  include: 


o  Using  surplus  equipment 
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o  Use  of  timesharing  services,  and 

o  Expanding  existing  systems  contracts  to  upgrade  individual 
components  of  the  current  system  to  improve  throughput 
capability  > 

Surplus  ADP  equipment  could  be  acquired  from  other  DOI  bureaus  or  other 
Government  agencies.  This  equipment  could  be  used  to  selectively  improve  the 
capability  of  specific  locations  as  required.  GSA  publishes  and  distributes 
to  Federal  agencies  a  list  of  available  excess  ADP  equipment.  Interested 
agencies  may  obtain  the  equipment  at  a  cost  which  is  significantly  less  than 
the  original  equipment  acquisition  price. 

Timesharing  would  allow  BLM  users  to  gain  access  to  the  computational 
services  of  an  external  computer  system.  Timeshare  services  could  absorb  some 
of  BLM's  applications  or  systems  development  work  based  on  criteria  set  by 
BLM.  This  would  release  some  of  BLM's  existing  ADP  capacity  for  other 
applications.  Timeshare  services  can  be  obtained  from  either  commercial 
vendors  or  from  other  Government  facilities.  The  Multiple  Award  Services 
Contract  (MASC)  schedule  provides  Government  agencies  with  a  schedule  of 
vendors  qualified  to  provide  timeshare  support  using  a  simplified  procurement 
vehicle.  In  addition.  Federal  agencies  can  acquire  commercial  timesharing 
services  through  the  General  Service  Administration's  Teleprocessing  Service 
Program  (TSP) .  Timeshare  services  can  also  be  obtained  through  a  competitive 
procurement,  typically  using  a  Basic  Ordering  Agreement  (BOA). 

Expanding  existing  contracts  would  allow  BLM  to  upgrade  individual 
components  of  its  systems  to  improve  performance.  Specific  upgrades  will  most 
likely  be  limited  by  the  terms  of  the  contract. 

4.1.3  Replacement  of  ADP  Equipment 

Under  this  alternative,  the  installed  ADP  system  is  replaced  with  an 
ADP  system  that  will  support  BLM's  functions.  BLM  has  the  following  options 
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under  this  alternative: 

o  Acquire  Government  surplus  equipment 
o  Timeshare 

o  Replace  ADP  systems  with  compatible  systems  that  will 
handle  the  workload,  and 

o  Competitive  replacement  of  ADP  system  through  use  of 
functional  specifications 

Acquiring  government  surplus  equipment  to  replace  BLM's  existing  ADP 
environment  would  be  contingent  on  an  entire  "systems-worth"  of  ADP  equipment 
being  on  the  Availability  List. 

The  timesharing  alternative  would  entail  contracting  with  a  remote 
computing  agency  to  handle  all  of  BLNTs  ADP  needs.  Feasibility  would  be 
limited  by  the  existence  of  vendors  who  could  provide  all  services  required  by 
BLM  to  perform  its  mission. 

Replacement  of  the  current  ADP  system  with  a  compatible  system  that  will 
handle  the  workload  involves  the  acquisition  of  ADP  equipment  that  is  entirely 
compatible  with  the  existing  system.  This  implies  that  no  conversion  of 
applications  and  programs  will  be  necessary.  An  example  of  this  alternative 
would  be  replacing  the  existing  computer  systems  with  computers  with  increased 
capacity  that  can  run  all  programs  currently  run  on  the  existing  systems. 

Competitive  replacement  of  the  installed  ADP  system  involves  issuing  a 
Request  For  Proposals  (RFP).  The  RFP  would  outline  the  functional  (and 
optionally,  the  technical)  requirements  which  the  system  would  need  to 
satisfy. 


4.2  Acquisition  Alternatives  Eliminated  From  Further  Consideration 


Certain  of  the  above-mentioned  alternatives  are  eliminated  from 
further  consideration  because  they  either  fail  to  meet  a  mandatory  requirement 
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(e.g.,  ability  to  handle  the  current  and  future  workload  of  BLM)  or  are 
clearly  inferior  to  the  other  options  (for  reasons  such  as  higher  cost,  larger 

risk,  etc.)’  Those  eliminated  include: 

\ 

o  All  alternatives  falling  in  the  "Use  of  non-ADP 

resources"  category 

o  Those  options  involving  the  use  of  surplus  equipment,  and 

o  Those  options  involving  the  use  of  timeshare  services 

4.2.1  All  Alternatives  Falling  in  the  "Use  of  Non-ADP  Resources"  Category 

The  alternatives  available  to  BLM  which  involve  improving  system 
utilization  and/or  developing  improved  manual  procedures  so  there  is  less 

reliance  on  the  ADP  system  clearly  cannot  meet  BLM's  future  needs  for  ADP. 

Even  with  the  current  ADP  support,  the  workload  is  at  times  .overwhelming. 
In  addition,  with  the  implementation  of  the  new  system  developments  (e.g., 
ALMRS,  GIS)  the  workload  will  be  significantly  greater.  Meeting  the  projected 
workloads  under  any  of  these  alternatives  would  result  in  greatly  increased 
labor  costs  due  to  the  number  of  new  hires  required  to  handle  the  workload. 
This  is  an  important  factor  since  there  is  a  lot  of  pressure  on  Federal 
agencies  to  cut  back  on  staff  rather  than  increase  it. 

Most  important,  none  of  these  alternatives  can  result  in  improved  service 
to  industry  and  the  general  public  because  the  available  resources  of  the 
current  ADP  configurations  will  not  be  able  to  provide  the  capacity  and 
performance  required  by  BLM  to  process  work  faster  and  more  efficiently. 

4.2.2  Those  Options  Involving  the  Use  of  Surplus  Equipment 

Augmenting  BLM's  ADP  resources  with  surplus  equipment  is  not  suitable 
for  meeting  BLM  ADP  requirements.  The  technical  capabilities  required  for 
modernization  could  not  be  met  by  utilizing  surplus  equipment.  BLM  requires 
state-of-the-art  systems  for  efficient  processing. 
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The  major  purpose  of  modernization  is  to  eliminate  fragmented  activities. 
Off-loading  applications  to  yet  another  set  of  ADP  equipment  will  not  lead  BLM 
any  closer  to  a  cohesive  set  of  ADP  capabilities.  Replacing  the  entire 
existing  ADP  system  with  government  surplus  equipment  would  only  be  feasible 
if  there  was  sufficient  surplus  equipment  available  from  other  agencies  to  put 
together  an  integrated  system  that  could  handle  BLM's  workload.  Items  on 
GSA's  Availability  List  are  generally  single  storage  units  or  peripherals 
rather  than  complete  hardware  systems.  In  the  long  run,  used  equipment  would 
probably  result  in  higher  overall  costs  (due  to  high  maintenance  expenses) 
than  implementing  a  new  architecture.  In  addition,  any  large  system  imple¬ 
mented  from  surplus  equipment  would  most  likely  result  in  dissimilar  hardware 
components  and  different  versions  of  software  which  is  the  direct  opposite  of 
the  major  objective  of  BLM's  modernization  effort. 

4.2.3  Those  Options  Involving  the  Use  of  Timeshare  Services 

Contracting  with  a  commercial  vendor  to  augment  existing  ADP 
resources  will  not  bring  BLM  any  closer  to  its  goal  of  an  integrated  ADP 
environment. 

For  the  high-volume  user,  timesharing  should  not  be  used  to  replace 
internal  computer  systems  —  local  or  remote  batch  processing  is  far  better 
than  timesharing  for  certain  applications.  Timesharing  facilities  are 
generally  used  in  addition  to  in-house  computing  for  such  things  as 
unscheduled  work  (e.g.,  COBOL  compiles),  applications  which  an  organization 
feels  can  be  more  economically  obtained  from  an  outside  service,  or  for 
"extra"  computing  resources  (e.g.,  where  CPU  requirements  cannot  meet  peak 
requirements) .  Using  timesharing  services  for  all  of  BLM's  ADP  needs  would 
not  be  a  feasible  option. 

4.3  Evaluation  Criteria  for  Acquisition  Alternatives 


AMS  identified  several  evaluation  criteria  in  the  previously 
mentioned  deliverable.  Certain  of  these  criteria  are  the  accomplishment  of 
BLM's  ADP  modernization  effort  and  thus  are  utilized  to  evaluate  the  remaining 
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set  of  acquisition  alternatives.  Each  of  these  clearly  influences  the 
feasibility  of  the  acquisition  alternatives  for  solving  BLM's  ADP  needs. 
These  include: 

o  Flexibility 

o  Integration  of  Applications,  and 

o  Compatibility  with  Existing  Systems 

4.3.1  Flexibility 

The  ADP  system  must  have  the  flexibility  to  adapt  to  future  needs  and 
work  loads.  The  system  must  be  able  to  provide  not  only  a  near-term  solution 
to  BLM's  ADP  needs,  but  also  be  expandable  to  accommodate  future  program 
growth  and  new  applications  and  permit  movement  of  processing  resources  as 
required  to  support  increased  or  decreased  workload  requirements. 

4.3.2  Integration  of  Applications 

One  of  the  major  purposes  of  the  BLM  Modernization  initiative  is  to 
eliminate  the  duplication  of  effort  and  overlapping  functions  and  to  examine 
the  potential  of  a  fully  integrated  hardware,  system  software,  and  data 
communications  environment.  At  present,  BLM  has  a  variety  of  applications 
running  on  different  vendor's  systems.  Many  of  these  applications  have  common 
data  sets;  but  since  the  systems  are  incompatible,  the  same  information  is 
being  re-keyed.  In  addition,  many  of  BLM  applications  utilize  common 
processes  (e . g . ,  much  of  the  software  needed  to  provide  for  BLM's  records 
functions  have  overlapping  characteristics  with  the  software  required  for 
resource  functions). 

Because  of  current  system  incompatibilities,  there  is  much  duplication  in 
performing  GIS  activities  (e.g.,  mapping  and  data  collection  policies).  The 
ability  to  exchange  data  among  systems  will  eliminate  the  duplication  of 
effort,  and  thus  should  lead  to  increased  productivity. 
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4.3.3  Compatibility  With  Existing  Systems 

If  the  new  technical  architecture  is  "compatible"  with  the  existing 
BLM  technical  architecture,  the  time  and  cost  incurred  in  moving  to  the  new 
technical  architecture  will  be  decreased  due  to  the  reduction,  or  elimination, 
of  a  major  conversion  effort.  Transportation  of  applications  and  data  to 
dissimilar  systems  cannot  be  accomplished  directly.  Conversion  of  code, 
formats,  etc.  is  required  so  the  new  system  can  "understand"  the  old  data  and 
programs. 

4.4  Evaluation  of  Acquisition  Alternatives 

The  set  of  alternatives  remaining  to  be  analyzed  include: 

o  Alternative  1  -  Expansion  of  existing  systems  contracts 

to  upgrade  individual  components  of  the  current  systems 
in  order  to  improve  throughput  capability 

o  Alternative  2  -  Replacement  of  existing  ADP  systems  with 
a  compatible  systems  that  will  handle  the  workload 

o  Alternative  3  -  Competitive  replacement  of  ADP  system 

through  the  use  of  functional  specifications 

In  the  remainder  of  this  section,  each  of  the  above  alternatives  will  be 
evaluated  with  respect  to  how  well  each  satisfies  the  criteria  presented  in 
the  preceding  section.  Figure  4-1  summarizes  how  well  each  of  these 
alternatives  satisfy  each  criterion. 

It  should  be  noted  here  that  within  BLM,  alternative  1  and  2  are 
functionally  equivalent.  Because  there  are  no  other  vendor  systems  compatible 
with  Honeywell  systems,  replacement  of  the  whole  system  would  have  to  be  with 
Honeywell  products.  This  would  make  the  option  of  replacing  the  ADP  systems 
with  compatible  systems  functionally  similar  to  expanding  the  current  systems 
contract  to  upgrade  the  system  to  handle  the  workload. 


4-9 


FIGURE  4  - 1 

A  Competitive  Procurement  Provides  the 
Best  "Fit”  for  Acquisition  of  BLM’s 
New  Technical  Architecture 
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4.4.1  Alternative  1  -  Expansion  of  existing  systems  contracts  to  upgrade 

individual  components  of  the  current  systems  to  improve  throughput  capability. 

The  capacity  of  the  current  systems  contracts  are.  such  that  the 
upgrading  of  individual  components  will  not  meet  BLM's  performance  needs. 

BLM's  current  ADP  facilities  include  many  different  (and  largely  incompatible) 
components.  Expansion  under  the  existing  systems  contracts  would  only  serve 
to  amplify  the  problems  already  stemming  from  incompatibility  among  BLM 
systems  (e.g.,  major  inefficiencies  due  to  duplication  of  effort  and 
overlapping  functions).  The  modernization  initiative  was  undertaken  to  ensure 
adequate  automation  support  of  current  and  future  BLM  mission  requirements. 
And  this  includes  eliminating  the  cost  and  processing  inefficiencies  resulting 
from  incompatible  systems.  In  addition,  BLM's  problems  are  not  isolated  such 
that  a  minor  upgrade  would  suffice.  They  are  wide-spread  and  encountered  at 
virtually  every  computer  site. 

4.4.2  Alternative  2  -  Replacement  of  existing  ADP  systems  with  a  compatible 
systems  that  will  handle  the  workload 

The  new  applications  being  developed  (e.g.,  ALMRS,  GIS)  may  require 
more  processing  and  support  resources  than  all  of  the  existing  applications 
combined.  A  compatibil ity-1 imited  replacement  will  not  satisfy  the  ADP 
requirements  of  the  new  systems  because  the  only  fully  compatible  systems 
available  cannot  meet  BLM's  future  processing  needs. 

This  alternative  would  satisfy  the  criteria  that  the  new  technical 
architecture  be  compatible  with  the  existing  technical  architecture,  However, 
acquisition  of  larger,  compatible  systems  that  could  run  all  the  programs 
currently  run  on  the  systems  they  are  replacing  fails  to  meet  the  requirement 
for  system  compatibility  "across  the  board".  Systems  integration  is  one  of 
the  major  goals  of  the  modernization  effort,  and  by  replacing  dissimilar 
systems  with  systems  compatible  to  each  individual  system  will  not  solve  BLM's 
problem  of  incompatibility  across  systems. 

In  addition,  if  BLM  were  to  expand  in  such  a  way  that  existing 
applications  are  not  to  be  affected,  a  sole  source  acquisition  with  Honeywell 
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would  be  necessary  since  Honeywell  compatibility  would  be  required.  This 
would  limit  BLM's  ability  to  obtain  discounts  for  ADP  equipment  and  will 
probably  not  be  approved  for  acquisition  by  GSA.  Of  equal,  if  not  greater, 
importance  is  the  fact  that  this  alternative  would  result  in  a  perceived 
restraint  of  competition. 

4.4.3  Alternative  3  -  Competitive  replacement  of  ADP  system  through  the  use 
of  functional  specifications 

Because  a  competitive  procurement  involves  distributing  an  RFP 
outlining  the  functional  —  and  perhaps,  technical  -  specifications  which  must 
be  met  by  any  proposed  system,  all  criteria  can  be  satisfied  under  this 
alternative.  Submitted  proposals  must  satisfy  the  requirements  outlined  in 
the  RFP  thus  assuring  (hopefully)  BLM  of  an  architecture/conf iguration  that 
will  meet  the  ADP  requirements  necessary  for  BLM  to  effectively  and 
efficiently  accomplish  its  mission. 

In  addition,  a  competitive  procurement  would  allow  BLM  to  take  advantage 
of  the  large  price  reductions  typically  offered  by  vendors  in  a  large  scale 
competitive  procurement. 

It  is  not  known  at  this  time  if  under  this  alternative,  the  criteria  of 
compatibility  with  existing  systems  will  be  met  or  not.  Until  a  specific 
vendor  is  selected,  the  software  migration  effort  cannot  be  determined. 

4.5  Comparison  of  Acquisition  Alternatives 

It  is  important  to  understand  that,  when  evaluating  alternative 
technical  architectures,  certain  evaluation  criteria  are  clearly  important 
discriminators.  That  is,  satisfaction  of  these  criteria  are  critical  to  the 
success  of  the  project.  With  respect  to  acquisition  alternatives  for  BLM's 
Modernization  effort,  the  criteria  for  application  integration  is  the  key 
differentiating  factor.  Given  this  assumption,  the  alternative  which  best 
satisfies  the  evaluation  criteria  is  to  competitively  procure  an  integrated 
ADP  system  based  on  BLM's  functional  and  technical  ADP  requirements. 
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Expanding  existing  systems  under  current  systems  contracts  or  replacing 
existing  systems  with  larger,  compatible  systems  will  not  provide  BLM  with  the 
flexibility  or  performance  the  Bureau  needs  in  its  ADP  environment.  Required 
system  capacity  will  increase  enormously  due  to  the  new  system  developments 
underway  (e.g.,  ALMRS,  GIS);  and  the  capacity  of  the  current  systems  are  such 
that  upgrade  of  individual  components  will  not  meet  the  required  performance 
criteria. 

One  of  the  major  objectives  of  the  modernization  initiative  is  to  ensure 
that  ALL  of  BLM's  systems  (e.g.,  purely  administrative  systems, 
case/operations  processing  systems  (such  as  ALMRS),  and  land  and  resource 
inventory  and  analysis  systems  (such  as  GIS))  are  fully  and  effectively 
supported  by  an  integrated  AOP  and  data  communications  environment.  The 
options  of  expanding  existing  resources  or  replacing  them  with  compatible  ones 
may  solve  future  capacity  problems,  but  will  not  provide  for  more  efficient 
and  cost  effective  ADP. 

4.6  Summary  and  Recommendations 

As  described  above,  both  alternatives  1  and  2  have  fatal  flaws  which 
prevents  them  from  being  viable  feasible  alternatives  for  acquiring  ADP 
equipment.  Neither  provides  for  the  integration  of  records,  resources,  and 
coordinate  data.  BLM's  existing  ADP  facilities  already  include  many  different 
components  which  are,  to  a  great  extent,  incompatible.  Upgrading  individual 
components  or  replacing  all  systems  with  larger,  compatible  systems  will  not 
alleviate  any  of  the  problems  which  currently  exist  (e.g.,  re-keying  due  to 
the  inability  to  share  data  or  programs,  necessity  to  manage  multiple  support 
teams  and  maintenance  contracts,  etc.). 

AMS  believes  that  the  competitive  procurement  process  is  the  best  means 
for  acquiring  the  ADP  and  data  communications  equipment  required  for  BLM's  ADP 
modernization.  No  other  source  can  provide  BLM  with  a  solution  that  will 
satisfy  the  Bureau's  needs  for  flexibility,  compatibility,  and  performance. 

Of  course,  if  BLM  elects  to  replace  the  existing  system,  there  are  other 
acquisition  issues  that  must  be  resolved.  These  were  outlined  in  the 
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Definition  of  Alternative  Concepts  for  the  Bureau  of  Land  Management  ADP 

Modernization  Project  previously  referenced  and  will  be  resolved  as  part  of 
this  project  at  a  later  date. 


. 

*■ 


5.0  STANDARDS 


Given  the  criteria  that  ALMRS  development  will  proceed  before  the  ADP 
Modernization  hardware  and  software  procurement,  BLM  (in  conjunction  with  AMS) 
has  selected  standards  for  the  ALMRS  development  which  will  be  incorporated 
into  the  Modernization  procurement.  The  major  objective  of  setting  these 
standards  is  to  allow  ALMRS  application  software  development  to  proceed  before 
hardware  and  system  software  vendors/products  have  been  selected  for  ADP 
Modernization  while  minimizing  the  risk  of  incompatibility  between  the 
development  environment  and  the  environment  provided  by  Modernization.  Since 
any  incompatibility  requires  a  conversion  effort,  with  resulting  costs,  these 
standards  will  facilitate  reduction  of  the  implementation  costs  for  ALMRS  and 
Modernization. 

This  chapter  presents  the  results  of  a  meeting  of  February  11-13,  1987, 
whose  purpose  was  to  set  some  standards  so  ALMRS  development  could  proceed 
prior  to  the  selection  of  a  technical  architecture  for  the  ADP  modernization 
effort.  Those  present  included  representatives  from  the  BLM  IRM/TAC 
Committee,  Field  Committee  representatives,  the  ALMRS  and  GIS  Project  Manager, 
representatives  of  the  Division  of  Information  Resource  Management,  and  the 
AMS  ADEMP  project  team.  AMS  presented  specific  areas  where  standards  should 
be  defined  in  order  to  coordinate  the  ALMRS  and  ADP  Modernization  efforts. 
These  included:  - 

o  Operating  Systems  Standards 

o  Spatial  Graphics  Standards 

o  Data  Base  Management  Systems  Standards 

o  Communications  Standards,  and 

o  Languages 

For  each  area  defined,  AMS  outlined  the  options  available  and  the 
implications  for  each  with  respect  to  functionality,  portability,  flexibility 
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(e.g.,  to  incorporate  new  technologies  and  products  or  to  expand  or 
reconfigure  to  meet  changing  functional  and  workload  requirements),  life  cycle 
costs  (e.g.,  hardware,  software  development  and  maintenance,  training, 
support),  and  risk  (e.g.,  cost  overrun,  schedule  slippages  procurement 
protest,  obsolescence). 

5.1  Operating  Systems  Standards 

Operating  systems  are  an  integral  part  of  the  computing  environment. 
They  are  the  programs,  implemented  in  either  software  or  firmware,  that  make 
the  hardware  usable.  Five  options  were  outlined  for  operating  system 
standards: 

o  No  standard 

o  Vendor  proprietary  operating  system 

o  POSIX  (proposed  UNIX-like  standard) 

o  Vendor  independent  proprietary  operating  system  (PICK) 

o  Specified  proprietary  operating  system 

5.1.1  No  Standard 


Under  the  "no  standard"  option,  the  Modernization  vendor  would  supply 
whatever  operating  system  they  felt  best  met  the  requirements  of  BLM, 
regardless  of  the  ALMRS  development  environment. 

The  implications  for  this  option  are  as  follows: 

o  Functional  -  Each  vendor  would  be  provided  maximum  flexibility  to 
provide  needed  functionality  and  optimum  performance  in  hardware  and 
system  software.  It  would  be  difficult,  however,  to  achieve  a  single 
user  interface.  Data  sharing  among  applications  and  sites  would  be 
significantly  more  difficult  if  multiple  operating  systems  are  used. 
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o  Portability  -  Unless  there  is  a  common  operating  system  interface, 
applications  cannot  be  moved  between  computer  systems  without 
requiring  some  conversion.  For  complex  applications  such  as  ALMRS 
and  GIS,  this  conversion  cost  may  be  prohibitive.  In  addition,  with 
no  standard,  vendors  may  elect  to  install  multiple  operating  systems 
within  BLM  (e.g.  both  Mod  400  and  GCOS  8  or  both  VM  and  MVS),  making 
conversion  of  ALMRS  to  the  new  environments  even  more  time  and  money 
consuming. 

o  Flexibility  -  No  standard  will  encourage  vendors  to  propose  and 

provide  their  own  proprietary  operating  systems.  These  vendor 
proprietary  operating  systems  may  make  incorporating  new  products  and 
technologies  difficult  and  more  expensive  thus  complicating  upgrade 
and  expansion. 

o  Life  Cycle  Cost  -  The  initial  acquisition  cost  may  be  minimized 

because  the  vendor  will  be  providing  an  operating  system  of  his 
choice.  However,  applications  development  and  maintenance,  training, 
and  support  will  be  higher  if  applications  must  be  developed  to  work 
and  users  trained  to  work  with  multiple  operating  systems. 

o  Risk  -  If  there  is  more  than  one  operating  system  specified,  this 

option  has  a  high  probability  of  cost  overrun  and  schedule  slippage 
due  to  the  increased  complexity  of  the  total  system.  In  addition, 
multiple  operating  systems  increases  the  likelihood  of  obsolescence 
since  some  of  the  operating  systems  specified  may  not  be  maintained 
and  upgraded  to  incorporate  technical  advances  on  a  timely  basis. 
With  respect  to  procurement,  not  specifying  a  standard  would  lead  to 
the  maximum  amount  of  competition  and  thus  the  minimum  risk  of 
protest. 

5.1.2  Vendor  Proprietary  Operating  System 

The  "vendor  proprietary  operating  system"  option  would  require 
vendors  to  provide  a  single  operating  system  for  all  processors  without 
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specifying  which  one. 

The  implications  for  this  option  are  as  follows: 

\ 

o  Functionality  -  Under  this  approach,  there  are  no  functional  or 

performance  requirements  that  could  not  be  met.  In  addition,  it 

would  allow  some  vendors  to  offer  a  wider  range  of  software  and  other 
products,  though  the  availability  of  software  would  depend  on  the 
specific  operating  system. 

o  Portability  -  ALMRS  would  have  to  be  converted  from  the  environment 

in  which  it  is  developed  to  the  one  in  which  it  would  run. 

o  Flexibility  -  The  incorporation  of  new  technologies  and  products 

would  depend  on  the  specific  vendor.  Expansion  and  reconf iguration 
would  depend  on  the  parameters  of  the  RFP. 

o  Life  Cycle  Cost  -  Under  this  alternative,  there  would  be  the 
potential  for  reduced  hardware  costs  due  to  optimization.  However, 
costs  would  be  incurred  for  ALMRS  conversion. 

o  Risk  -  Since  this  option  entails  a  competitive  procurement,  there 

would  be  little  risk  of  protest  with  respect  to  acquisition. 
Obsolescence  would  depend  on  the  specific  vendor. 

5.1.3  POSIX 

POSIX  will  support  the  execution  of  the  same  programs  on  various 

computers  running  different  resident  operating  systems  (i.e.,  portability). 

The  POSIX  standard  is  being  developed  by  a  committee  working  under  the 
Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  and  the  National  Board 
of  Standards  (NBS).  When  the  standard  is  approved  it  is  expected  to  be 

incorporated  into  the  General  Service  Administration's  (GSA)  Federal 
Information  Resources  Management  Regulations  (FIRMR). 
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The  UNIX  operating  system  provides  an  interface  for  portable 
applications,  but  all  versions  of  this  operating  system  are  proprietary  and 
thus  not  available  for  standardization.  The  POSIX  standard  is  expected  to  be 
approved  in\  mid  to  late  1987.  It  is  important  to  note  that  this  standard  is 
actually  an  operating  system  interface  for  portable  applications.  The  initial 
standard  only  addresses  applications  written  in  the  language  "C".  Portable 
applications  can  be  written  in  other  traditional  languages,  such  as  COBOL  and 
FORTRAN,  but  the  language  interfaces  are  implementation  dependent.  POSIX  will 
provide  the  required  functionality  to  support  portable  source  code  for  a  wide 
range  of  applications  for  various  computers  and  operating  systems.  Because  of 
the  way  the  standard  is  being  constructed,  implementations  may  be  done  by 
methods  the  implementor  finds  will  provide  the  needed  functionality  and 

optimum  performance  in  hardware  and  system  software. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  This  UNIX-like  operating  system  will  provide 
extensive  capabilities  for  technical  computing  and  office  automation. 
The  COBOL  compilers  currently  available  for  UNIX-like  systems  are 
weak  (e.g.,  with  respect  to  compilation  times  and  production  of 
"fast"  code),  but  improvements  can  be  expected.  Because  of  the 

growing  use  of  UNIX-like  systems,  many  third  party  applications  are 
being  developed. 

o  Portability  -  ALMRS  and  other  new  BLM  applications,  if  properly 

written,  would  only  require  recompilation.  However,  use  of  POSIX 
does  not  guarantee  that  applications  are  portable.  Rigorous 
management  control  of  programming  styles  and  usage  are  necessary  to 
ensure  portability.  For  example,  the  "C"  language  allows  the 
implementation  of  data  pointer  to  vary  on  16-bit,  32-bit,  36-bit,  and 
64-bit  computers.  Programs  that  make  implicit  assumptions  about 

pointers  will  fail  when  moved  to  machines  with  differing 

architectures. 

o  Flexibility  -  The  POSIX  standard  should  cover  a  wide  range  of 

processor  sizes  so  expansion  and  reconfiguration  will  be  a  simple 
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matter.  If  POSIX  gains  wide  acceptance,  vendors  will  develop  a  lot 
of  products  that  are  compatible. 

o  Life  Cycle  Cost  -  The  POSIX  standard  provides  a  highly  productive 
software  development  environment  because  it  allows  for  software 
portability.  Conversion  of  properly  written  software  (and  its 
associated  costs)  are  reduced  or  totally  eliminated. 

o  Risk  -  It  is  likely  that  POSIX  will  elicit  a  wide  range  of  vendor 
support.  Major  vendors  like  AT&T,  UNISYS,  and  DEC  already  support 
UNIX-like  operating  systems.  If  the  standard  becomes  widely  used  and 
supported,  the  chance  of  obsolescence  is  negligible.  There  is  a  high 
risk  for  large  COBOL  applications  since,  at  present,  there  are  no 
strong  COBOL  compilers  marketed  for  UNIX-based  systems.  Performance 
and  availability  for  office  automation  and  technical  applications  is 
good.  If  management  controls  are  not  enforced,  there  is  significant 
risk  that  the  portability  advantages  of  POSIX  will  not  be  realized. 

The  specification  of  POSIX  will  have  procurement  implications  that  are  not 
immediately  apparent.  The  following  discussion  is  from  the  National  Bureau  of 
Standards  discussion  paper  titled  POSIX:  An  emerging  standard  for 
(Applications)  Software  Portability: 

A  benefit  POSIX  can  not  provide  is  to  relieve  the  Federal 

Agencies  of  the  important  tasks  of  writing  well  thought  out 

solicitations  (RFI,  RFC,  RFP)  and  carefully  evaluating  proposed 
systems  for  their  capability  to  meet  specified  requirements.  A 
system  which  is  POSIX  conforming  only  insures  that  programs  designed 
for  portability  to  that  standard  will,  in  fact,  run  on  that  system. 

It  does  not  promise  any  level  of  performance  or  guarantee  any 

functionality  beyond  that  specified  in  the  standard. 

For  those  procurements  where  a  benchmark  is  appropriate,  the 
POSIX  standard  could  potentially  reduce  the  cost  by  making  it 

easier  to  move  the  benchmark  form  one  system  to  another.  The  costs 
may  be  lowered  enough  to  allow  benchmarks  in  some  situations  where 
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it  might  have  been  marginally  too  expensive  without  the  capability 
to  easily  transport  the  benchmark.  The  transportable  benchmark  will 
also  facilitate  benchmarking  a  real  application  as  opposed  to  a 
synthetic  benchmark  whose  results  may  be  less  reliable  and  less  well 
understood.  The  closer  one  can  come  to  running  the  application  for 
which  the  system  will  be  used,  the  higher  confidence  one  can  have 
that  the  system  will  indeed  perform  as  required. 

Due  to  probable  wide  variety  of  computer  systems  that  will  be  used  to 
support  BLM  applications  during  the  ten  year  scope  of  Modernization,  the 
ability  to  easily  and  inexpensively  perform  benchmarks  will  be  a  significant 
benefit. 

5.1.4  Other  Vendor  Independent  Operating  System 

Other  operating  systems  are  available  (e.g.,  PICK)  and  may  be 
specified  in  both  the  ALMRS  and  Modernization  RFPs. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  Depending  on  the  specific  software,  there  may  be 

limited  functionality,  availability  of  third  party  software,  and  a 
limited  number  of  processors  on  which  the  operating  system  software 
will  run. 

o  Portability  -  ALMRS  would  be  developed  and  ported  to  a  new  hardware 
environment  without  conversion,  given  that  the  hardware  supported  the 
specified  proprietary  operating  system. 

o  Flexibility  -  This  would  be  limited  by  the  specific  operating  system. 

o  Life  Cycle  Cost  -  This  would  be  determined  also  by  the  specific 
operating  system  acquired. 

o  Risk  -  Risk  under  this  option  would  be  high  because  there  may  not  be 
wide-spread  support  of  the  operating  system  software. 
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5.1.5  Specified  Proprietary  Operating  System 

Under  this  option,  the  ALMRS  team  would  select  the  specific  operating 
system  best  suited  for  the  ALMRS  application  and  which  could  support  other  BLM 
applications.  Both  the  ALMRS  RFP  and  the  Modernization  RFP  would  specify  that 
particular  operating  system. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  This  alternative  would  provide  the  best  fit  of  BLM 
application  needs  because  it  was  actively  selected  as  "best  suited". 

o  Portability  -  All  applications  would  be  directly  portable  since  the 
operating  systems  will  be  identical. 

o  Flexibility  -  Incorporation  of  new  products  and  technologies  would  be 
dependent  upon  the  operating  system  specified.  Expansion  and 
reconfiguration  would  depend  on  the  parameters  of  the  RFP. 

o  Life  Cycle  Cost  -  Initial  acquisition  cost  may  be  high  due  to  the 
absence  of  a  competitive  procurement. 

o  Risk  -  Software  development  risk  is  low,  because  the  optimum 
operating  system  was  selected.  Procurement  will  most  likely  be 
protested  or  disapproved  since  a  sole  source  award  eliminates  fair 
competition. 

5.1.6  Operating  System  Resolution 

The  option  proposed  as  a  standard  for  all  BLM  field  machines  was  the 
Portable  Operating  System  for  Computer  Environments  (POSIX)  standard.  The 
software  portability  delivered  under  POSIX  provides  a  highly  productive 
software  development  environment.  Many  manufacturers  plan  to  implement  the 
standard  when  it  is  approved  as  a  full  use  standard  (this  is  expected  to  be  in 
Oecember,  1987). 
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The  operating  system  for  BLM-wide  administrative  applications  was  left 

open. 


5.2  Spatial  Graphics  Standards 

A  large  component  of  resource  management  work  involves  spatial  analysis 
and  graphics.  Any  system  that  is  configured  for  use  by  resource  specialists 
in  BLM  field  offices  must  provide  these  capabilities.  Thus  setting  a  graphics 
standard  is  also  important.  The  three  options  discussed  were: 

o  No  standard 

o  Graphical  Kernal  System  (GKS) 

o  Others  (e.g.,  PHHIGS,  CORE) 

5.2.1  No  Standard 

The  "no  standard"  option  would  allow  vendors  to  specify  whatever 
graphics  interface  they  considered  would  best  meet  BLM  needs. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  Since  the  vendor  may  specify  the  graphics  interface 
he  feels  will  best  meet  the  requirements  of  the  RFP,  there  are  no 
limits  on  functionality.  In  addition,  not  having  a  standard  graphics 
interface  would  allow  for  maximum  use  of  third  party  software  (e.g., 
GIS). 

o  Portability  -  New  software  drivers  may  have  to  be  written  for  ALMRS 
to  be  run  in  a  new  environment. 

o  Flexibility  -  There  is  a  limit  to  what  technologies  and  products  can 
work  with  non-standard  software. 
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o  Life  Cycle  Cost  -  Because  there  is  a  potential  for  high  optimization, 
this  option  provides  a  low  use  of  hardware  resources.  However, 

effort  must  be  expended  to  develop  graphics  applications  for  custom 
applications  such  as  ALMRS.  Vv 

o  Risk  -  The  degree  of  risk  is  high  because  of  the  difficulty  of 

writing  graphics  processing  routines  and  the  high  probability  that 
the  system  will  be  constrained  to  use  specific  hardware  output 
devices. 

5.2.2  Graphical  Kernal  System 

The  Graphical  Kernal  System  specifies  the  interface  between 
application  programs  and  graphic  input  and  output  devices.  It  has  been 
adopted  as  an  American  National  Standards  Institute  (ANSI)  and  International 
Standards  Organization  (ISO)  standard  and  is  the  most  widely  accepted  of  the 
graphics  standards. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  Some  graphics  functions  are  not  included  in  this 

standard  (e.g.,  3-0,  though  it  is  under  development).  In  addition, 

much  GIS  software  (e.g.,  MOSS)  does  not  comply  with  GKS. 

o  Portability  -  ALMRS  graphics  software  could  be  ported  to  the  new 

environment,  and  a  variety  of  output  devices,  plotters,  color  CRTs, 
etc.  can  be  used  without  change  to  the  software. 

o  Flexibility  -  The  use  of  GKS  would  facilitate  adding  new  devices 

since  standards  are  already  specified.  Software  development  may  be 
constrained  by  the  capabilities  within  the  standard.  These 

constraints  can  be  overcome,  but  at  the  cost  of  additional 

development. 

o  Life  Cycle  Cost  -  Because  a  standard  is  specified,  there  may  be 
reduced  optimization  and  thus  higher  hardware  resource  requirements. 
However,  resources  will  not  have  to  be  expended  to  develop  graphics 
routines. 
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o  Risk  -  In  general,  GKS  minimizes  risk  by  allowing  ALMRS  graphics  to 
be  developed  in  an  industry  standard,  device  independent  method. 
There  is  a  small  risk,  however,  that  GIS's  spatial  graphics 
requirements  will  exceed  thexcapabi 1 ities  of  GKS,  resulting  in  higher 
development  costs. 

5.2.3  Others 

In  addition  to  GKS,  there  are  other  graphics  standards  in  use  and 
under  development.  These  include  the  Programmer's  Hierarchical  Interactive 
Graphics  Standard  (PHIGS),  the  CORE  System,  and  the  Initial  Graphics  Exchange 
Specification  (IGES). 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  Each  standard  offers  different  functionality. 

o  Portability  -  Any  which  provided  the  features  required  by  ALMRS  would 
facilitate  portability  to  the  new  environment. 

o  Flexibility  -  The  extent  of  use  and  support  of  these  standards  is 
uncertain. 

o  Life  Cycle  Cost  -  As  with  the  preceding  alternative,  because  a 
standard  is  specified,  there  will  most  likely  be  reduced  optimization 
and  thus  higher  hardware  resource  requirements.  Resources  will  not 
have  to  be  expended  to  develop  graphics  routines. 

o  Risk  -  The  risks  associated  with  these  other  standards  are  similar  to 
those  discussed  with  GKS,  but  these  standards  are  more  specialized 
than  GKS  and  may  present  additional  costs  if  their  capability 
diverges  from  the  BLM  requirements. 
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5.2.4  Graphics  Resolution 

It  was  proposed  that  GKS  be  used  as  a  graphics  presentation  standard 
for  ALMRS,  but  not  for  GIS. 

5.3  Data  Base  Management  System  Standards 

The  data  base  management  system  (DBMS)  is  the  software  that  handles 
all  accesses  to  stored  data  files.  A  standard  database  management  interface 
will  allow  BLM  applications  to  share  data.  The  four  DBMS  alternatives 
discussed  were: 

o  No  standard 

o  Vendor  specific  package 

o  Standard  Query  Language  (SQL) 

o  CODASYL 

5.3.1  No  Standard 


Under  the  no  standards  option,  the  Modernization  RFP  would  include  a 
functional  specification  for  a  DBMS. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  Each  application  development  project  would  select  the 
DBMS  package  that  is  optimum.  This  would  guarantee  that  the  needed 
functionality  is  provided.  This  would  not  provide  any  guaranteed 
inter-appl i cat ion  functionality. 

o  Portability  -  The  ALMRS  software  would  have  to  be  converted  to  use 
the  DBMS  acquired  with  the  Modernization  RFP  (given  that  they  are  not 
the  same). 
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o  Flexibility  -  With  no  standard,  each  application  could  possibly 
select  their  own  optimal  OBMS  package,  which  would  increase 

flexibility  for  that  development  effort.  The  use  of  conflicting  DBMS 
packages  for  multiple  packages  would  seriously  inhibit  the 
flexibility  to  share  data  and  algorithms. 

o  Life  Cycle  Cost  -  This  option  would  entail  ALMRS  conversion  costs  if 
the  Modernization  DBMS  package  was  different.  However,  there  is  the 
potential  for  reduced  hardware  costs  due  to  optimization. 

o  Risk  -  This  option  has  the  least  risk  for  any  given  application 

development  effort,  but  has  unacceptably  high  risk  for  BLM  as  a 
whole. 

5.3.2  Vendor  Specific  Package 

Under  this  alternative  the  ALMRS  team  would  select  the  DBMS  best 
suited  for  the  ALMRS  application  and  BLM  would  specify  it  in  both  the  ALMRS 
and  Modernization  RFPs. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  This  option  would  provide  an  excellent  functional  fit 
as  the  vendor  will  select  the  DBMS  that  best  meets  the  functional 

requirements  of  the  RFP. 

o  Portability  -  The  ALMRS  portability  objective  would  be  met  since  the 
DBMS  used  in  development  would  be  the  same  used  in  the  new 

environment. 

o  Flexibility  -  The  incorporation  of  new  technologies  and  products 

would  be  limited  by  the  specifics  of  the  DBMS. 

o  Life  Cycle  Cost  -  Hardware  costs  may  potentially  be  lower  due  to 
optimization.  However,  initial  procurement  may  be  high  due  to  the 
absence  of  a  fully  competitive  procurement. 
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o  Risk  -  Because  a  specific  DBMS  will  be  defined  in  the  RFP,  one  or 
both  procurements  are  likely  to  be  disapproved  or  protested. 

Development  risks  are  low  because  the  ALMRS  team  would  actively 
select  the  best  package. 

5.3.3  Standard  Query  Language 

Under  this  alternative,  vendors  would  specify  any  data  base 
management  package  they  felt  could  best  meet  BLM's  needs  on  the  condition  that 
it  support  SQL.  SQL  was  originally  developed  by  IBM  for  use  with  their  DB2 

DBMS.  It  includes  a  user  language  and  programming  interface  for  relational 

data  base  management  systems.  Although  implementations  vary  slightly,  SQL  has 
been  adopted  by  many  DBMS  vendors  (e.g.,  Cullinet,  DEC,  IBM,  Oracle, 
Information  Builders,  Informix,  Unify,  etc.). 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  SQL  provides  all  relational  data  management  functions 
though  it  is  inefficient  for  high  volume  transaction  processing 
(which  is  not  a  major  issue  within  BLM). 

o  Portability  -  The  SQL  interface  would  allow  ALMRS  to  be  ported 

directly  to  the  new  environment  if  the  specific  version  of  SQL  was 
specified  and  enforced. 

o  Flexibility  -  SQL  is  becoming  an  industry  standard  and  many  new 

products  (e.g.,  gateways  to  other  packages)  are  being  developed.  The 
relational  data  model  is  the  most  flexible  organization,  with  far 
better  flexibility  than  hierarchical  or  network  models. 

o  Life  Cycle  Cost  -  Hardware  costs  may  be  higher  due  to  inefficiencies 
of  some  vendor's  implementations. 

o  Risk  -  SQL  is  supported  by  a  growing  number  of  vendors.  Since 
multiple  vendors  can  provide  BLM  with  SQL,  there  is  little  risk  of  a 
procurement  protest.  Deficiencies  and  limitations  within  the  ANSI 
SQL  specification  require  vendor  extensions.  Use  of  these  extensions 
greatly  increased  risk  and  cost  of  conversion  to  new  packages. 
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5.3.4  COOASYL 


Under  this  alternative,  a  vendor  may  specify  any  database  package 
that  conforms  with  the  COOASYL  standard.  The  COOASYL  standard  is  a  standard 
for  network  data  base  design  and  does  not  handle  relational  data  bases  (which 
are  far  more  flexible  than  network  or  hierarchically  organized  data  bases)  or 
include  standards  for  user  language  or  program  interface. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  COOASYL  is  designed  for  high  volume,  high  performance 

production  systems.  Relational  features  are  not  addressed  by  the 

COOASYL  standards.  The  relational  approach  to  data  storage  and 
manipulation  is  the  most  flexible  of  all  possible  approaches  (i.e., 
relational,  hierarchical,  network). 

o  Portability  -  Data  portability,  but  not  application  software 

portability,  will  be  provided.  Vendor  specific  implementations 

prohibit  application  portability. 

o  Flexibility  -  Within  a  given  environment,  COOASYL  databases  trade 

flexibility  for  performance.  Vendor  specific  implementations 
seriously  limit  flexibility  across  vendor  products. 

o  Life  Cycle  Cost  -  Hardware  costs  may  be  higher  due  to  inefficiencies 
of  some  vendor's  implementations.  Software  support  cost  will 
probably  be  significantly  higher  compared  to  a  relational  model. 

o  Risk  -  Because  the  COOASYL  standard  is  really  an  architectural 
standard,  each  vendor's  product,  though  it  may  conform  to  the  COOASYL 
standard,  will  be  vendor  specific.  This  greatly  increases  the  risk 
and  cost  of  conversions  to  new  packages.  In  addition,  a  network 
organization  is  much  more  complex  than  a  hierarchical  organization, 
and  would  be  much  more  difficult  for  programmers  to  work  with;  thus 
increasing  the  risk  of  inefficient  application  development. 
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5.3.5  DBMS  Resolution 


It  was  proposed  that  SQL  be  designated  as  the  standard  interface  forx 
the  ALMRS  development  effort. 

5.4  Communications  Standards 

There  were  three  options  available  with  respect  to  communications. 
These  included: 

o  No  standard 

o  Transmissions  Control  Package/Internet  Protocol  (TCP/IP) 

o  International  Standards  Organizations/Open  Systems  Interconnect 
( ISO/OS I )  Standard 

5.4.1  No  Standard 


Under  the  "no  standard"  option,  the  vendors  would  specify  the 
communication  protocols  they  felt  best  meet  the  requirements  of  8LM. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  Vendor  specified  communications  software  might 

provide  BLM  with  maximum  functionality  (due  to  optimization) 

initially,  but  functionality  may  be  limited  if  the  communications 
specified  is  not  widely  supported  because  it  would  be  difficult  to 
incorporate  advances  in  communications  technology  and  to  achieve  an 
interface  between  a  non-standard  communications  network  and  outside 
systems. 

o  Portability  -  The  ability  to  port  applications  and  databases  between 
dissimilar  systems  would  be  limited. 
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o  Flexibility  -  Lack  of  a  standard  will  encourage  vendor  proprietary 

communications  systems  (e.g.,  IBM's  SNA,  Digital  Equipment 

Corporation's  DECNet,  etc.)*  There  may  not  be  a  wide  variety  of 
products  available  for  communications  between  these  proprietary 

systems.  In  addition,  the  use  of  non-standardized  communications 
products  could  lock  BLM  out  of  technical  advances  in  communications. 

o  Life  Cycle  Cost  -  Because  there  are  less  products  available  for  less 
supported  communications,  there  may  be  costs  associated  with  custom 
development  of  required  communications  extensions.  Custom 

development  and  support  of  communications  software  would  be 

prohibitively  expensive.  In  addition,  if  BLM  has  to  support  more 
than  one  communications  network,  two  or  more  separate  support  staffs 
may  be  necessary. 

o  Risk  -  The  risk  of  obsolescence  would  be  very  high  with  a  non¬ 

standard  communications  system. 

5.4.2  TCP/IP 

TCP/IP  is  widely  used  in  the  network  marketplace.  It  is  the  only 
proven  communications  protocol  that  can  provide  inter-operabi 1 ity  between 
dissimilar  systems.  This  standard  was  originally  developed  by  the  Department 
of  Defense  Advanced  Research  Projects  Agency  (DARPA)  to  link  its  various 
systems  and  has  since  been  refined. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  TCP/IP  supports  a  host  of  network  applications 

including  Network  File  Transfer  for  moving  files  across  the  network. 
Network  Virtual  Terminal  for  remote  terminal  traffic.  Simple  Mail 
Transmission  Protocol  for  sending  electronic  mail  packets,  and 
Sockets  for  task  to  task  communications  such  as  mainframe  to 
mainframe  processing. 
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o  Portability  -  TCP/IP  can  provide  interoperabil ity  between  dissimilar 
computer  systems. 

o  Flexibility  -  TCP/IP  is  not  proprietary.  It  is  supported  by  a 
growing  number  of  vendors.  In  addition,  it  can  run  side  by  side  with 
other  communications  protocols  (e.g,,  OSI),  allowing  great 

flexibility. 

o  Life  Cycle  Cost  -  More  than  300  vendors  support  TCP/IP,  thus  initial 
procurement  and  maintenance  costs  can  be  expected  to  be  lower  (due  to 
competition) . 

o  Risk  -  There  is  little  risk  associated  with  this  alternative  as  the 
protocol  has  been  widely  tested. 

5.4.3  IS0/0SI 

The  International  Standards  Organization  created  the  OSI  model  based 
upon  seven  "layers"  of  communications:  physical,  data  link,  network, 

transport,  session,  presentation,  and  application.  The  purpose  of  these  seven 
layers  is  to  define  the  various  functions  that  must  be  carried  out  when  two 
machines  communicate. 

The  implications  for  this  option  are  as  follows: 

o  Functionality  -  Standards  for  the  first  four  layers  are  generally 
accepted  but  standards  for  the  remaining  of  three  layers  are  still 
under  development.  Because  of  this,  viable  commercial  products  based 
on  OSI  standards  are  still  at  least  two  years  away. 

o  Portability  -  Once  IS0/0SI  is  fully  implemented,  portability  of  data 
will  be  greatly  simplified. 

o  Flexibility  -  Vendor  support  for  the  forthcoming  IS0/0SI  standard 
will  provide  a  wide  variety  of  hardware  and  software  from  which  BLM 
could  choose. 
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o  Life  Cycle  Cost  -  This  cannot  be  predicted  at  this  time  as  there  are 
no  commercially  marketed  complete  ISO/OSI  products  available  at  this 
time. 

o  Risk  -  Risk  is  high  today  because  the  standard  is  not  complete.  When 
all  standards  are  finalized,  risk  will  be  very  low. 

5.4.4  Communications  Resolution 

Because  TCP/IP  standards  offer  vendor  independence  and  connectivity 
for  dissimilar  machines  today,  it  was  proposed  that  BLM  specify  TCP/IP  as 
their  communications  standard  and  migrate  to  ISO/OSI  when  OSI  standards  are 
fully  developed  and  accepted.  Migration  to  OSI  from  TCP/IP  is  possible 
through  standard  network  interfaces  (e.g.,  IBM's  NetBIOS). 

5.5  Languages 

AMS  and  BLM  also  discussed  which  language  interpreters  or  compilers 
the  new  technical  architecture  must  support.  These  include  languages  which 
currently  play  a  role  in  BLM  applications.  Selection  of  supported  compilers 
did  not  reguire  the  in-depth  analysis  of  alternatives  as  did  the  other  issues 
discussed  in  this  chapter.  Thus,  only  the  results  of  this  discussion  are 
presented  here. 

It  was  proposed  that  the  technical  architecture  support  the  following 
programming  languages: 

o  BASIC 

o  C 

o  COBOL  74  and  8X 


o  FORTRAN  77  and  8X 
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Other  languages  the  architecture  must  be  capable  of  supporting  for 
possible  incorporation  at  later  date  include: 

o  PASCAL 

o  LISP 


o  PROLOGUE 


6.  ENSUING  STEPS 


The  next  task  facing  the  AMS  project  team  is  to  perform  a  detailed 
analysis  of  the  costs  and  benefits  of  the  technical  architecture  alternatives 
presented  in  this  report  and  the  cost  of  telecommunications  for  each.  The 
project  team  will  present  technical  architecture  recommendations  at  the 
conclusion  of  this  analysis.  We  intend  to  use  a  Workload  Analysis  Model  to 
predict  the  CPU  sizes,  the  number  of  input/output  channels,  and  the  number  of 
disk  drives  necessary  for  each  alternative  configuration  identified  in  Chapter 
4  of  this  report.  These  figures  will  then  be  input  into  a  cost  model 
developed  by  AMS  to  determine  the  approximate  cost  of  each  alternative  to  be 
used  in  Task  8 ' s  Economic  Analysis. 

6.1  The  Workload  Analysis  Model 

AMS  will  model  each  alternative  configuration  to  estimate  the 
processing  resources  necessary.  The  model  we  will  use  is  a  combination  of  the 
public  domain  CP80  sizing  model  (developed  by  IBM)  and  an  AMS  proprietary 
model.  The  CP80  model  estimates  CPU  size,  number  of  Input/Output  (I/O) 
channels,  and  required  Direct  Access  Storage  Device  (DASD)  capacity  given  a 
situation-specific  set  of  parameters  called  R-factors.  The  R-factors  supply 
the  CP80  model  with  information  about  application  demands  and  system  demands 
for  CPU  cycles  and  I/O.  Empirically  determined  algorithms  are  used  to 
translate  these  CPU  and  I/O  demands  given  by  the  R-factors  into  estimates  for 
CPU,  I/O  channel,  and  DASD  sizing. 

AMS  has  developed  a  portion  of  the  sizing  model  which  transforms 
estimates  of  transaction  volumes,  transaction  complexity,  batch  processing 
workloads,  and  desired  peak  CPU  workload  into  the  R-factors  needed  by  the  CP80 
model.  We  have  simplified  the  determination  of  the  R-factors  by  allowing  the 
computing  resource  estimate  to  be  stated  in  terms  of  average  and  peak 
transaction  rates  for  on-line  resources  and  file  size,  and  processing  window 
for  file  driven  (batch)  processes.  Transaction  rates  are  divided  into  three 
categories  of  complexity  —  simple,  average,  and  complex  —  based  on  the 
average  CPU  and  average  physical  I/Os  performed  by  the  transaction.  Batch 
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processes  are  also  categorized  based  on  average  CPU  cycles  and  average  number 
of  I/Os  per  record.  Based  on  the  transaction  counts  given  in  the  batch 
processing  and  on-line  processing  volume  estimates,  the  AMS  model  calculates 
the  R-factors  for  the  CP80  model. 

6.2  The  Model's  Application  to  CPU  Sizing  for  BLM*s  Technical 
Architecture 


AMS  has  been  collecting  all  of  the  data  necessary  to  feed  into  our 
model  in  order  to  generate  the  above-mentioned  R-factors  needed  by  the  CP80 
sizing  model.  The  results  of  the  modeling  process  estimate  sizing  for  an  IBM 
configuration.  These  results  are  then  extrapolated  to  other  vendor 
configurations. 

6.3  Task  8  -  The  Economic  Analysis 

The  purpose  of  Task  8  is  to  recommend  an  effective  technical 
architecture  which  identifies  the  best  overall  approach  to  implementing  a 
modernized  ADP  technical  architecture. 

The  technical  architecture  alternatives  to  be  considered  in  Task  8  are 
those  defined  in  Chapter  4  of  this  document.  Each  alternative  will  be  defined 
in  terms  of  its  potential  benefits  to  BLM,  weaknesses,  key  dependencies,  major 
cost  drivers,  and  implications  for  the  Bureau. 

In  order  to  estimate  technical  architecture  costs  for  each  configuration, 
AMS  will  model  each  architecture  using  the  Workload  Analysis  Model  described 
in  section  6.1.  Industry  sources  will  be  used  to  determine  representative 
costs  for  the  different  architecture  components  (including  telecommunications 
costs). 

Issues  addressed  in  Task  8  include: 

o  The  location  of  computing  resources  (alternative  configurations 
identified  in  this  paper) 
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o  Local  office  architecture  (e.g.,  single  processor,  multiple 
processor,  networking  approach),  and 

o  Wide  area  communications 

Costs  will  be  estimated  for  each  alternative  technical  architecture 
broken  down  by: 

o  Baseline  (based  on  initial  workload)  vs.  maximum  projected  workload 

o  Type  of  office  (small  vs.  medium  vs.  large) 

o  Cost  component  (e.g.,  wide  area  communications,  processor,  terminal, 
etc.) 

o  Application  (e.g.,  ALMRS,  OA,  Admin,  etc.) 

6.4  Remaining  Tasks 

Based  on  the  results  of  Task  8,  AMS  will  develop  a  high  level  action 
plan  for  implementing  the  selected  technical  architecture.  This  plan,  Task  9, 
will  address  the  acquisition  approach  for  the  technical  architecture,  the 
overall  schedule  for  procurement  and  implementation,  and  the  installation  and 
phase-in  approach. 

In  parallel  with  the  development  of  the  Implementation  Plan,  AMS  will 
develop  the  technical  specifications  BLM  will  need  to  develop  the  RFP(s)  to 
procure  the  selected  technical  architecture.  This  will  be  presented  to  BLM  as 
Task  10. 

The  schedule  for  this  study  calls  for  all  tasks  to  be  completed  by  the 
end  of  FY  1987. 
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